On 7/7/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > Personally I prefer to keep form beans and value objects seperate, for two > key reasons: > > 1) form beans generally should consist of String data to facilitate > round-tripping of invalid inputs. I like to constrain them to a clearly > defined role of marshaling data 'into' and 'out of' the presentation layer, > i.e. across the boundary between presentation and application.
Is not it easier to have one nested VO/BO with string properties, than to copy properties back and forth from action form to VO? I use web framework only to expose my real objects to the outer world. > 2) value objects should use typed interfaces to ensure marshaling to and > from presentation format (string types) is pushed as far up the application > stack as possible. This also enables other, potentially type-aware, > presentation / client tiers to be built on top of the same value objects > (e.g. for a web-services interface). I think I do not agree with this one. Let's take it as a design requirement that application that we build is a webapp. It potentially can have different interfaces. This would mean, that: * input data is stingified because of HTTP * Struts is not the only front end Therefore, it is much easier to create BO/VO with dual string/typed interface or with string interface only. It would do validation and conversion to native datatype internally instead of doing it in validate() method. I believen that this is more flexible approach. What are you going to do with your validation code, if you are told to move from Struts to WebWork or Tapestry? On 7/8/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > Form beans are part of the *view* tier, not the model ... their > purpose in life is to represent the server side state of the HTML > elements on a form, even if that state is invalid (i.e. not currently > passing all the validations). That way, you can reproduce what the > user typed so he or she can fix it, rather than presenting them with a > completely blank screen. (This is why you generally use string fields > in a form bean). This is one way to look at things. Another way is to use VO/BO for input/output directly. When I use existing data, I load it into BO and display it. When I modify it, I update BO using its string properties. If I decide to cancel updates, I siply remove the BO from memory, no database changes needed. If I create a new object, I create a new BO and fill it in. Until I persist it, it hangs in the session. If I decide to cancel, then I remove it, and database would not even know that I was about to insert an object. > In a component oriented framework like JSF or Tapestry, you don't need > to worry about keeping track of this state information ... the > components do it for you. JSF still differentiates "real" object (whatever it might be, a real business object or a VO) from visual component data, which I don't like. From my point of view, it is much easier to have an object with an ID, to view/edit it, or to delete it. Therefore, I do not need viewstate for UI components. I only need to store my object somewhere like in session while I work with it. I want my widgets and my view to be as dumb as possible. All data and state that I need is in real objects, I do not need artificial viewstate to duplicate it. I can understand why JSF or ASP.NET went this route with UI objects and viewstate: to abstract from the model/business layer. They do not want to establish a firm contract with business/persistence layer. They do not want to require a certain BO lifecycle or the datatype limitations. But I as a developer find this inconvenient. Web frameworks designers focus on their framework, while I as an application designer, focus on business data, business process and business state. Take ActiveX. There is a contract, there are interfaces, methods and datatypes defined. Just build an object according to the protocol, and you will be able to have design-time interface, runtime interface, everything. Web frameworks do not want to have strict contracts with data layer probabaly to be more flexible. I would take contract over flexibily anytime. Presuming that this is a flexible contract ;-) Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
