Sorry, Michael, I accidentally sent this directly to you . . .
I'm not sure why you say "save a call to the backend" unless by "backend" you mean anything outside of the web tier. In my applications, it would typically save a call to the manager layer, which I consider the middle, not the backend. It would not typically save a call to the persistence layer -- the backend -- as managers usually don't need to access a persistent store to perform manager-layer validation (I suppose there are exceptions). So, different layer, as you say, but same VM usually. For a much-distributed application, I could see the argument about saving the call to any other layer, but, I would need another solution for that problem, such as a local manager. I don't typically have any classes that resemble what you are describing as a "business object". I typically have managers, value objects, helper objects (mini-managers if you will), and data access objects. Value objects are the only ones that cross tier boundaries, and they are completely dumb. This creates weak coupling, which I prefer. I don't recall having any business object classes that had the same fields as value objects plus business logic. I suppose back when I was writing entity beans there might have been some. Now, I have managers which operate on the other object types. Business logic is in the managers. Data is elsewhere (generally). Erik -----Original Message----- From: Michael Jouravlev <[EMAIL PROTECTED]> Sent: Jul 7, 2005 8:16 PM To: Struts Users Mailing List <user@struts.apache.org>, [EMAIL PROTECTED] Subject: Re: Using struts forms as Value Objects: your opinion? On 7/7/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > An alternative would be to have your form class extend > your value object class. However, this approach doesn't > work for me. My form class fields are always Strings > (because of HTTP), while my value object fields are > whatever types make sense (such as Date). I always have > value object classes that look very similar to my forms, > but the types vary. It doesn't bother me. What is the point of having strong typed VOs? They are neither BOs (no behavior), nor actionforms. Why not to use BOs directly? Someone is going to check for business rules, why not to do it while data is still on web layer? Can save on call to backend. It seem to be a religious argument, and different approaches are good for different situations, but *generally* I would think that using BOs directly is easier and faster. One can say that app can evolve. BOs can evolve one way, and UI another way. Well, then create another BO instead of creating another VO. What is the difference? I will have several BOs working with more or less same data. How bad is that? Oh, right, I have to update web layer. As if one does not have to update web layer, when one modifies VOs. Ultimately all goes to database anyway. Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
