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. 2007/6/23, Marcos Chicote <[EMAIL PROTECTED]>:
Thanks Ulrich! I was also considering that. Whath do you think about BO in the presentation layer? I think the correct solution would be to use Presentation Object and do the getDepartamentChief().getName() there. I believe POs should not know about the presentation layer, so my solution would be to use departament.chiefin the Insert componente, but Departamente property in Tapestry's java would actually be something of class DepartamentePO and when I create the PO I do the getDepartamentChief().getName(). What do you think about that? Thanks! On 6/23/07, Ulrich Stärk <[EMAIL PROTECTED]> wrote: > > Marcos, > > You should also consider that when traversing the object tree with ognl > you might run into runtime > exceptions when you change for example the name of a getter and forgot to > adjust your ognl > expression. If you did that navigation in the page class the compiler > would warn you of a > non-existing getter at compile time. On the other hand doing it with an > ognl expression right in > your html template or page specification will save you some writing. > > Uli > > Marcos Chicote schrieb: > > Thanks Marcus! > > I know Tapestry will implement the method for me, and that both ways > work. > > The question is which of those would you use? Is anyone better from a > > design > > point of view than the otherone? Are they the same? > > > > The problem is that if, for example, some day Users BO is no longer of > use, > > and the class is deleted, compilation problems would show in the .java > (if > > we are using alternative 2) and it would be simpler to correct, but > nothing > > would show the problem if alternative 1 is used. > > > > On 6/23/07, Marcus <[EMAIL PROTECTED]> wrote: > >> > >> > >> > http://tapestry.apache.org/tapestry4/tapestry/ComponentReference/Insert.html > >> > >> > >> or > >> > >> http://tapestry.apache.org/tapestry4 in menu Fremawork -> Components > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
