struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew O'Haire <MOha...@fm.optus.net.au>
Subject RE: deep nesting of value objects in a form bean
Date Tue, 02 Oct 2001 00:18:00 GMT
for anyone interested.. here's the URL to the project...
http://www.tstrata.trysoft.com <http://www.tstrata.trysoft.com>  
 
it's an extranet app, so there isn't too much facinating stuff to look at.
;-)
 

-----Original Message-----
From: Matthew O'Haire [mailto:MOhaire@fm.optus.net.au]
Sent: Tuesday, October 02, 2001 10:12
To: 'struts-user@jakarta.apache.org'
Subject: RE: deep nesting of value objects in a form bean



I've sucessfully used a VO structure in a struts app and 
used dot notation to access the data in just the way you 
describe.  However, in our case the VO's were immutable. 

O.K., now for my 2c worth... 

I'd be very careful using "generic" update methods like 
updateVO() to process business logic.  Say you have an 
object with some state and you need to perform a state 
transtion (A->B) you could do this by changing the state 
value, or by calling a method that describes the state 
transtion (i.e. startEngine()).  If you simply change 
the data, the "business logic" for allowable transitions 
is in your client code... and the situation can only get 
worse as more and more data values change.  For example, 
say a transition requires an associated date, now you need 
to change two values in combination (see how the business 
logic creeps down to your client) rather than using a method 
(i.e. cancelOrder(Date cancelDate)).  If you opt for an API 
to encapsulate the business operations on your Entities then 
you'll have a much cleaner interface, you'll be able to see 
the business operations supported by the API and you'll 
achive greater seperation of business/presenattion logic. 
Some patterns to consider for this are Session Facade and 
Business Delegate. 


Mime
View raw message