On Fri, 14 Mar 2003, Phil Steitz wrote:
> Date: Fri, 14 Mar 2003 10:17:59 -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 > > 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. > This is certainly a valid concern at the point where you're talking about data that can be *updated* by a web application. However, it's reasonable to pay attention to the fact that well over 80% of the SQL statements executed by a typical webapp are SELECTs that are only grabbing data to be rendered in the UI. Forcing people to create BOs for all of that stuff seems like it doesn't add a ton of value add. > Unless what you mean is to use the RowSetDynaClass to populate your BOs...? > That's certainly feasible as well, although it probably adds an extra layer without much benefit -- the population code has to know about the persistence tier pretty intimately already. > 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.... > Yes, it is tying the tiers together. Now, assume we did the "right O-O design" and created value objects in between. Isn't the design of those value objects (specifically, which properties you expose) just as tied to the persistence tier? And isn't the set of properties available to the view tier just as tied to the set of properties available through the value objects, whether it's exposed as a bean or a JDBC row? A very typical thing that happens when you're adding features to an existing app is that you need to make some additional dynamic data avalable. Using value objects, you have to modify the VO class *and* the SQL code that populates it. Using RowSetDynaClass, you get to bypass part of that work, and only update the SQL query. Note that I am *not* advocating doing the query itself in the view tier (i.e. the JSP page). What you want is that the page author sees a collection of beans representing the results of the query, passed as a request attribute. In fact, if you're using the Struts tags to iterate over the collection and extract properties from it, the page author cannot even *tell* whether it's really dynabeans or not (in other words, the back end developer can change the implementation choice without affecting the front end pages). That's the way it should be. (In fact, if you follow my previous suggestion and isolate your SQL queries into a properties file, you can often accomodate the "add one more column" scenario with no changes to the back-end logic either -- just one tweak to the SQL statement that is already being executed.) > 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? > You're probably missing the point because I didn't emphasize it enough in my answer :-). I am *not* advocating using this technique for data that the webapp will be updating -- that should be done through business tier objects in the back end. However, there is a very large amount of read only data in any real life app. Think of RowSetDynaClass as my endorsement of making it easy to transport such data from the business tier to the view tier, without having to write any Java code, in the same way that DynaActionForm lets you create a form bean without having to actually create a Java class. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
