Michael Jouravlev wrote:
On 7/7/05, Laurie Harper <[EMAIL PROTECTED]> wrote:
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.
If you don't mind your VOs/BOs being untyped then sure, I guess it's
easier. Personally I'd rather use strongly typed interfaces as far as possible.
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
Just because the transport protocol is HTTP doesn't mean you're only
dealing with string data though. If I add a web services layer, I'll want
ot talk in terms of domain types. If I want to add some other RPC mechanism
the same will be true.
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?
I don't see the difference between having dual string/typed properites and
having the same thing split between two classes, other than making the one
class more confusing and error prone to use.
Most of my validation is handled by the Validator framework right now
which, admitedly, ties things to Struts to some extent (though there's no
reason I couldn't pull Validator 'down' a level and use it under some other
presentation technology if it didn't provide an equivalent.
L.
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.
--
Laurie, Open Source advocate, Java geek and novice blogger:
http://www.holoweb.net/~laurie/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
