You put all the view related logic there, ie sorting data, calling some services to update the data, ... If you use a layered architecture (well you should usually), the clue here is to think is this logic local to this page (or more if it is a session bean) ? Is this logic still make sense if I totally change the way the information is rendered? When you answer yes it's mean this logic is strongly related to the view and should be keep inside backing beans, if it is no, well it is a good clue this code should be moved inside the application business logic layer.
If you have Struts experience, thinks of backing beans as a mix of DispatchAction and ActionForm. Basically what they do is call services and expose the data in a way that make sense to the next page. BTW, if you use a tool for your persistance like Hibernate that support lazy loading and you are not going to deploy your business logic layer remotly, you don't DTO. IMO you can expose your business objects in the backing beans instead of constructing dumb DTOs. 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
