I agree wholeheartedly with both of James' points. Put it all in the same webapp until you are absolutely certain that you've outgrown that. And I don't like DTO's. Why is it "better" to return an object that only has three fields when you don't need all ten? Doesn't this imply that you've broken the separation of concerns - your service layer is coded to know what fields your view layer needs? Also, why have duplicate objects to have to maintain? And what would returning the extra fields hurt?
Anyway, just my two cents. -- Jeremy Thomerson http://www.wickettraining.com On Tue, Mar 24, 2009 at 11:02 AM, James Carman <[email protected] > wrote: > On Tue, Mar 24, 2009 at 11:56 AM, Eduardo Nunes <[email protected]> wrote: > > > > I always use DTO in service methods. My point of view is that if you > > have a method named "getSimpleUserList" and your User entity has 10 > > attributes and for this simple list you just need 3 of them, doesn't > > make sense to me return a Set of User objects, for that I would create > > a SimpleUserDto and return a Set of it. > > I'm not a big fan of DTOs. I understand why folks use them, but until > I figure out that I actually need them (for performance reasons), I > actually stick with just sending back my entities from the database. > For the most part, it works for me and I find it convenient to have > everyone coding to the same "domain" objects. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
