Except for rather small scoped projects, I prefer the usage of DTOs (or formerly known as 'View Objects') over direct usage of domain objects. DTOs can be modelled much closer to the use case (i.e. view) at hand (by combining domain objects or leaving out non-required attributes to have objects like e,g 'UsersAndTicketsVO').
If you are using an ORM tool like Hibernate there are some additional technical issues, if you intend to let the mapped domain objects propagate to the view layer: * LazyInitializationException issues (no more words on this here ;-) * Serialization can bite you in remote access scenarios (not very probable for a web application, though) because of the implicite dependency on some implementation classes like a HibernateSession. * Subtle but severe problems when you have to 'prepare' domain objects for the view, e.g. for security reasons. Consider a scenario where a user are only allowed to see some parts of a domain objects, e.g. a 'Protocol' which has 'ProtocolEntry' members where some of them are classified. If you now remove the classified 'ProtocolEntry' members before showing the protocol entries in a list view, and this happens within a Hibernate Session's boundary, then this entries will be removed from the DB as well (without an explicit call to some DAO). We use DTOs also for an addition abstraction layer (a facade), which provides use-case (client) specific service methods (with DTOs as arguments) and call out to domain specific services (hidden by interfaces of course) with domain objects on the other side. BTW, I had to learn all those things 'the hard way', so this is not a pure theoretical argumentation. Formerly, I was a firm advocat of 'avoiding DTOs at all cost', too ;-) If you need some tool support for using view objects (and to cut down the LOCs ;-), we find Dozer (http://dozer.sf.net/) for declarative, bean-wise mappings rather useful. ... roland Martijn Dashorst wrote: > > You could do that. If you are paid by the lines of code you write, it > might be even profitable. A lot of people prefer the direct binding > (which IMO is a POJO) instead of making a GUI bean (which would be a > DTO). > > Martijn > > On 2/14/08, mfs <[EMAIL PROTECTED]> wrote: >> >> Well i meant the same in my question..i dont think making your Domain >> Objects >> implement IModel would give any benefit rather would make the DO >> dependent >> on wicket (or the presentation layer)... >> >> So you advocate the idea of having the domain object wrapped inside >> wicket >> models..rather than having a seperate screen specific POJO...like >> AddressModelObject for AddressPanel, LoginModelObject for LoginPanel >> >> e.g. >> >> >> >> >> >> Mr Mean wrote: >> > >> > In our apps we always wrap our domain objects in models, not have them >> > implement IModel. >> > There is only 1 exception to this rule and that is because that >> > particular object is not stored in the db but is initialized with >> > loads of other objects. It turned out to be one very complex mofo not >> > something i would recommend. >> > >> > Maurice >> > >> > On Feb 13, 2008 7:30 PM, mfs <[EMAIL PROTECTED]> wrote: >> >> >> >> Guys, >> >> >> >> I would want to know if using your business/domain objects as wicket >> >> models >> >> would be a good idea ? >> >> >> >> i remember in an earlier thread i was suggested not to use >> >> business-objects >> >> as wicket models, but it would want to hear more opinions.. >> >> >> >> Thanks in advance.. >> >> -- >> >> View this message in context: >> >> >> http://www.nabble.com/Business-Domain-objects-used-as-wicket-model-object---opinions-please-tp15462661p15462661.html >> >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/Business-Domain-objects-used-as-wicket-model-object---opinions-please-tp15462661p15470590.html >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > Buy Wicket in Action: http://manning.com/dashorst > Apache Wicket 1.3.1 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Business-Domain-objects-used-as-wicket-model-object---opinions-please-tp15462661p15475043.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
