Database Components Considered Evil

Question

This is the most important adage since "GOTO considered harmful". Small applications can benefit from the convenience of binding data sources to forms and using SQL based queries in components. Making that available is an industry must; it is also just this side of evil.
Creating many small applications or a greater-than-small application should never fall victim to such a temptation; rather, in my opinion you should always abstract the database in data models that hide the underlying persistence strategy entirely. That way you manage data access in your data access package and publish APIs to the rest of the team for getting simple or complex models.
Just started using JSF (very, very promising technology that stands on the shoulders of midgets) and was diasppointed by the availability of UI database binding. It's a marketing reality that is also present in JSTL.

Answer 1

The advantage of DB Components, is you can just plonk 'em when you want them and they know how to display themselves automatically and follows the Encapsulation OO strategy. This been said, its a very bad idea to have sql statements within a DB component.... what happens if the database changes?
BUT, the best of both world solution is to have a Model - View component (Notice, no Controller!) - Where, instead of the view component containing the SQL, it contains a reference to a default model , and it is this model that contains the SQL to retrieve the data. The outcome is the same, just plonk the component on the screen, and it sorts itself out , however, the database remains abstract to the 'view' , the SQL is encapsulated within the model.... The database changes, it only requires changes to this default model for everything to continue to work.
So, using this methology, we can end up with a panel (the parent View) , containing lots of child views (Model-Views). These child views could also contain their own imbedded model-views. This is the composite pattern, and is mentioned by GOF.