Using Delphi data-aware components - pros and cons [closed]

Answer 1

I've found that using the data-aware components results in an application with no clear distinction between business and UI logic.

This is fine for small projects but as they grow larger the code becomes less and less maintainable.

All the various bits of event code (and their interactions) can become a real nightmare to understand!

Invariably in such cases I've ditched data-aware components and have switched to a (hand-coded) MVC design.

This does require a lot of up-front coding effort but results (IMHO) in a project that is maintainable, extensible and debuggable.

Answer 2

You can use Unidac which supports many database servers, including Firebird (that i use) and has very nice features.

Coupled with Remobject SDK you will have a nice combination of n-tier architecture and database abstraction.

Answer 3

Data-aware components are usful from a RAD and prototyping perspective, especially when you're designing reports or grids that are based on data. i.e. you can tinker at design time. So I use them like that. But when it comes time to transform it into shipping code, I almost always sever the connections, remove the SQL from the queries, and do everything in code. It's much more predictable and maintainable that way, especially in a multi-developer environment with version control. When the SQL is embedded in the form somewhere, it's a big pain to try to figure out where the SQL actually resides. And it's especially bad to have SQL in two places, and then have to figure out which is in effect.

Answer 4

Data aware controls are great, but you have to make sure you get your business code in a separate layer.

That is not difficult, but you need to be aware on how you can do that.

One approach is to have your DataSet components in a DataModule (or other non visual container).

Another handy trick is to use a TClientDataSet to do the UI entry, and use that as an intermediate buffer between the UI and the business layer. The business layer then uses TDataSet components specific to your data layer.

--jeroen

Answer 5

Take a look at ORM solutions.

It's a nice approach with multi-tier architecture. See ORM for DELPHI win32

Answer 6

Delphi data-aware components are not depended on the back-end database engine you are using, so using Firebird or MS SQL Server or Oracle or others doesn't matter to your data-aware components. They only know the datasource component assigned to them and do all their DB related stuff via that.

For me, if something can be done with data-aware components in a nice way, I will use them. These are usually small projects which should be done in a short-time. In bigger projects, I might totally rule out data-aware components or use them in forms that are merely used for data presentation and do not receive user input. When it comes to receiving user input, I might use non-data-aware components because I have more flexibility in controlling them and validate the input. Of course data-ware components can be still useful in such scenarios too. You still can validate user input in dataset events like OnBeforePost. Also if you are using a multi-tier design, and your client app represents data presenter layer, your input validation is done in the middle-tier so you can receive input using data-aware components in the client app, and send them to the middle-tier for validation and further processing.