I have a debating at work with developers with knowledge about .NET and Java, but minimum knowledge on Delphi. Debating is about using an architecture based on POJO objects instead of using TDataSet on a server application. I can't see any advantage of excluding the use of TDataset built-in functionality, and to create a small framework based on classes which map the tables from database. Server application is not designed to perform heavy CRUD operations. It just feed several .NET clients with data using RemObjects. I see a big disadvantage to create a plain class to hold values from a SQL select statement, instead of using a dataset. When the SQL is modified, or a table is modified, then all the classes need to be modified also. On the other hand, if using TDataset, developers should dedicate a small time involved to learn how to use Delphi datasets. Any thoughts on this?
It's difficult to make such a decision without knowing what kind of manipulation of data that is needed, and in what format they are passed on.
ReplyDeleteI think he's asking if it's better to store data in a TDataSet vs classes on the server side, e.g. CustomersDataSet vs CustomersObjList. And from there, the data is transformed via RemObjects into something the clients can use.
ReplyDeleteIf this is the case, why do the client developers care? Their primary concern is how to consume the data, not how the sausage is made in the sausage factory.
Are classes > TDataSet? They can be if you have lots of business logic around them. They are not if you are primarily doing CRUD. The answer might be a compromise. TDataSet by default. Classes when needed with a TDataSet->Class conversion to extract the record data, place in a class instance, and apply business logic.
Too many steps... for a data feed service. Delphi alone is more than capable to feed data directly, even .NET is capable to get the data it needs. KISS pls...
ReplyDelete