|
In our application, a typical model object is a slightly enhanced DTO containing the obvious primitives, other domain objects, getters and setters, but also methods that can be fully completed just by using data on the object itself (e.g. validate object fields, cloning the object...). Every other functionality like using the object in some use case flow or saving the object to persistency is done elsewhere (the object is passed as a parameter to other objects that do all the required work with this object). This way the object can travel safely between tiers without the risk of exposing a method on the wrong tier (e.g. call to save to persistency on the presentation tier).
Hope that helps... Uri.
On 2/9/06, Nicklas Karlsson <[EMAIL PROTECTED]> wrote: > A related architechture question I sometimes wonder about is: > > Should the model POJO:s be kept as clean DTO:s or should they have member > functions for operations also, and > if there are operations, how complex should they be allowed to be before I > should break them into e.g. static calls in > a business logic class? If they are not separated, the model and the > businessl logic melts into a mess. >
-- Alexandre Poitras Québec, Canada ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ |
