On Mon, Dec 14, 2009 at 6:51 PM, Thiago H. de Paula Figueiredo <thiag...@gmail.com> wrote: > Em Tue, 15 Dec 2009 00:34:25 -0200, Geoff Callender > <geoff.callender.jumpst...@gmail.com> escreveu: (Bravo Geoff!)
> You can be happy with relational persistence now, but maybe not tomorrow. ;) > Just to be very clear: when I say "JPA is not my DAO", I say "any class > outside my persistence layer doesn't use JPA directly". As long as you > define DAO interfaces that are technology-agnostic and your business rules > classes use them, I'm happy with any DAO implementation. :) That's just a typical overengineered design (http://en.wikipedia.org/wiki/Overengineering). You've changed languages and the hell has frozen many times over before you change your persistence layer *if* you started with a relational database. > I don't like anemic models, but I don't like entity classes that talk to > DAOs or business rules classes, like the domain-driven model people love to > do. I never have an entity class with a save() or findById() method. I like > to think that an object must implement anything it can do inside its data > structure, but never access anything beyond it (data store, external > systems). Surely transaction management is none of domain model's business, but if you can represent a pure business rule in your domain model, why not? You are not going to use that business logic anywhere else anyway. Exactly how many layers of indirection do there need to be? Most of the Java applications today are way over-engineered for their purpose - while RoR and php folks are running circles around us. Kalle --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
