I want to know your opinion about using data-aware components in projects. Which are the 'strength' and 'weak' points of developing applications(win32 and web), by using Delphi and data-aware components(from Delphi's standard suite or third-party)?
Using FireBird I've worked a lot with IBObjects, which are a mature suite of components and worked very well.
But there are also a lot of other RDBMS (MySQL, MSSQL, DB2, Oracle, SQLite, Nexus, Paradox, Interbase, FireBird etc). If you have developed big projects, on which you've used a lot data-aware components please answer with the database type and data-aware components suite name.
I'm also interested on DB2 (AS400). What components have you used with success, or which components are really a pain to work with?
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.
Having tried both data-aware and non data-aware style of Delphi applications I'm back in the data-aware component camp these days. It takes a bit of work and discipline to correctly layer the code but it's still quicker than doing everything by hand using non data-aware controls.
A few of my tips for data-aware component usage are
Don't just rewrite FishFact on a larger scale. Put some thought into your design.
Don't use a TDataModule, use many TDataModules each responsible for just a small aspect of your applications data.
TDatasets belong on TDataModules, while TDataSources belong on TForms (unless used for master/detail relationships).
Use in-memory datasets such as the DataSnap TClientDataSet.
Your ClientDataSets don't have to mirror your database tables exactly. DataSnap allows you massage your data structures in memory so you can produce datasets tailored for specific purposes. Specifically you can do things like
Joining two or more tables into the one editable dataset
Denormalizing master detail table structures, can simplify your UI code sometimes.
Create in-memory only fields (like calculated fields but you can write to them also)
TClientDataSet nested tables are useful but not the only way to express master detail relationships. Sometimes it's better to do it the old way with two independent TClientDataSets joined through a TDataSource.
Take a look at ORM solutions.
It's a nice approach with multi-tier architecture. See ORM for DELPHI win32
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
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.
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.
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.
来源：https://stackoverflow.com/questions/4722563/using-delphi-data-aware-components-pros-and-cons