i see what you mean Christian.
In this design if you have to show a Date, how do you convert it? I mean, if
you let Tapestry do date.toString() this will probably show a lot of things
you don't want. Do you use a property in the java file where you put
something like dateToString(yourDate) that does the parsing? Same question
for Double's or things that don't have a "nice" toString.

Thanks for your opinion!

On 6/24/07, Christian Dutaret <[EMAIL PROTECTED]> wrote:

Marcos,

The concept of a presentation object model has a strong smell of bad
design:
double hierarchy maintenance and transformation methods from/to both
models
which are very error-prone. If you forget to assign a field in those
transformation methods, you can spend hours searching for the descrepancy
between your model data.
Reminds me of that bloated DTO concept with the first generation of EJB,
or
the transformations between business model and ActionForms in Struts 1.
Very
time-consuming and error-prone, without any added value.
How often does your business model changes without affecting the
presentation layer? Is it worth all that pain?
The business model I work on is a relatively complex model which is
designed
after the web application requirements. What I do is simply use persistent
objects in the presentation layer, and traverse objects through ognl
expressions to keep the code as simple as possible. If the model evolves,
I
have some web non-regression tests that check for the correctness of the
ognl expressions. That has worked fine for me so far.
In some other situations (say a legacy datawarehouse that is used beyond
your application and holds some fancy data), an additional intermiedary
model could make more sense. Still, I would try to keep it at the service
level, and use the data returned by the service layer in the presentation
layer.

My 2 cents...
Ch.


Reply via email to