It's hard to unit test, or reuse, for example in JSTL or Model 1. It has a CVS hot spot. etc. etc.
Best stick with unit tested POJO (and a bean that has a DAO helper, as in my other posts).
.V
Phil Steitz wrote:
I apologize if this has already been beaten to death, but I am still struggling with the implications of "dyna-stuff" on traditional OOD in struts applications. See interspersed.
Craig R. McClanahan wrote:
This is pretty much what RowSetDynaClass does for you, without the need to
create classes for your value objects.
Yes, but then you no longer have encapsulation at the business object level. If you "short-circuit" the persistence => business objects => view path, then either the view or the persistence layer is going to have to absorb both data abstraction and business logic.
Unless what you mean is to use the RowSetDynaClass to populate your BOs...?
Or...maybe there is a class of applications where "persistence" really can effectively absorb both data abstraction and business logic?
* For read only data access i used an optimised SQL statement (plse see
below) which returns only enough data to render the current screen to the
client.
This is almost always a really smart strategy -- not only should you limit
which columns are retrieved to only those that meet the requirements, you
should (more importantly) limit the number of rows that is retrieved, as
Pat points out below.
Two possible concerns are that you'll be tying the persistence tier and the view tier together, because (for example) the page author has to know about the column names in the database, and the business logic has to be tweaked every time the page author needs a new column added. To mitigate these problems, I suggest using two strategies:
* Store the actual SQL query sources into properties files, so that it can be modified easily without touching the business logic classes. (This can also be a lifesaver if you have to support more than one database, where the SQL query syntax has to change slightly.)
* Use the column aliasing capability of SQL (the "as" modifier) to convert the database column names into simple names that the page author can expect, and document (for him or her) only those names. For example, a query might say something like:
select customer-account-number as account, external-display-name as name from customers where ...;
and the page author will see properties named "account" and "name", no matter what the database actually uses.
But isn't this effectively still binding the view tier to the persistence tier? How do you handle "derived fields"? Using SQL to encapsulate business logic can lead to a maintenance nightmare. First come views, then stored procedures, then more database dependency than you ever wanted....
I can see how simple CRUD apps can be assembled VERY quickly using dyna-stuff tied directly to a SQL data model, with the "model" really just being the data model (with techniques like the above used to loosen the coupling a bit); but this brings back some *BAD* memories for me -- "instant" 2-tier applications using "advanced data binding" technologies having to be rewritten entirely when they needed to scale (either in terms of load or complexity).
Am I just "once bitten, twice shy" here? Am I missing the point?
Craig McClanahan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
