On Fri, 14 Mar 2003, Phil Steitz wrote:
> Date: Fri, 14 Mar 2003 14:17:38 -0700
> From: Phil Steitz <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: Re: Data driven struts application
>
> Thanks, Craig.
>
> I understand a lot better now, but I am still struggling a bit.
>
> What you seem to be saying is that for read-only access we can safely
> "skip" the value/business object encapsulation; but for updates, we
> should use real BOs. This asymmetry troubles me; though I see the
> appeal in terms of developer productivity. I still see the risk of
> becoming persistence-implementation dependent, however, even with
> "externalized SQL" and field name normalization using AS. I see how the
> "Dynamic" model easily accomodates adding new fields to views, etc; but
> what happens when you decide to re-engineer the data model or to bring
> in a new datasource altogether? Or when you need to add "derived fields"?
>
There's no question that you risk misbehaving ... but remember two things
that are critically important about my suggestion:
The page author has no clue that the ResultSetDynaClass
instance you passed was delivered directly from the
JDBC query ... to him/her, it just looks like a List of
beans.
The business tier is still responsible for *creating*
that List of objects, and placing it in an appropriate
request parameter. The business tier author can change
that implementation to use "real" VOs, or pull the data
from EJBs or an LDAP directory server instead, with zero
impact on the page author or the code in the page.
Therefore, I would contend that my solution is no more tied to the
persistence tier than VO-based solutions are (i.e. you have to agree on
the property names).
> Consider the following example. Suppose that I am developing an online
> banking site, enabling customers to do both inquiries and updates on
> their accounts. The account info is stored in an RDBMS and I use
> Dyna-stuff to hit the store directly (using a "model-free" BO) with SQL
> queries, quickly generating a flexible infrastructure for account data
> retrieval. For updates (only?) I develop a traditional middle tier,
> with BOs and VOs modelling the domain and encapsulating the business
> logic. All is well and good until my company acquires another bank that
> has a "legacy" back end. If my "update" BOs and VOs are cleanly
> defined, I will not have much of a problem engineering "connectors" to
> the new system so that the new accounts can look no different from the
> others; but I will be SOL for account retrieval (unless, once again, I
> am missing something). This example may seem contrived; but this kind of
> thing does happen.
>
My bank has a similar application (shudder ... they even used Struts to
build it ... :-). The app provides a combination of data I can modify
(change my profile, transfer money back and forth, etc.) and a whole bunch
of read-only data (all the current transactions, the account balances on
all the other accounts, and so on). The quantity of modifiable data is a
very small percentage of the total amount of dynamic data that is present.
And, any effort to build VOs that support modification of all that other
data would be overkill (for this app, although you might be able to use it
elsewhere).
Even if you adopt my suggestion to use RowSetDynaClass, you should hide
that actual logic behind a DAO of some sort, so that the Action calling it
doesn't know where the data came from either.
> One more point on the "adding fields" topic. I understand and agree
> with the basic point that if you use VOs, you need to keep them in synch
> with the model and you also need to keep the view in synch with them and
> that takes time. It also forces some analysis to be done, adds
> compile-time type checking, enhances readability of code and makes it
> easier to keep track of what data elements are being used in what way by
> what functions (so that implications of changes to the underlying data
> can be understood and fully tested). Call me a geezer; but somehow I
> prefer UML to SQL for design documentation. If the only artifacts
> expressing the design of the "read-only view" are SQL properties files,
> how do you keep these consistent with the model expressed in the BOs/VOs
> for updates?
>
If all of us were this disciplined, there would be a lot fewer software
bugs in the world :-). Unfortunately, there's lots of people who do
things quick and dirty -- I'm trying to help them without giving up
totally on MVC principles :-).
> I guess the best strategy depends on the expected lifetime and required
> extensibility of the application.
>
Yep.
> Thanks again for the explanation.
>
> -Phil
>
Craig
>
>
> ---------------------------------------------------------------------
> 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]
