On 14/12/2009, at 11:05 PM, Thiago H. de Paula Figueiredo wrote: > Em Mon, 14 Dec 2009 07:55:21 -0200, Alessandro Bottoni > <alexbott...@gmail.com> escreveu:
>> 3) In his Jumpstart's FAQ, Geoff Callender says: >> >> "Why did the Data Access Object pattern ever exist? As I recall it had >> two purposes: to abstract away the data sources, and to hide the >> implementation of accessing the data. > > I agree! > >> That is exactly what JPA (Java >> Persistence Architecture, also known as EJB3 Persistence) does too. So I >> argue that JPA has taken the place of the DAO and there's no need for us >> to write our own. JumpStart uses JPA as its DAO." > > I disagree. If a DAO exists the abstract away the data source and the > *implementation of accessing the data*, JPA is one implementation, Hibernate > is another, purde JDBC is another, etc. What if you want to change your > persistence to Google's BigTable (low-level API) or HBase or MongoDB or DB4O? > You have to change business rule code (they use JPA directly), and the DAO > pattern was created exactly to avoid this kind of sistuation. You got me - JPA targets relational databases, so if you think that one day you might need to re-engineer your project to use a non-relational database then maybe it would be worth writing DAOs now as an extra layer of abstraction. However, if you're happy to stick with relational, then JPA can be your DAO. You choose your relational persister at runtime, eg. Hibernate, TopLink, OpenJPA, etc. >> What do you think about this? Would you use the JPA entity also for >> hosting some business logic? > > I put in an entity all the logic that can be implemented just by using its > fields values. Example: if I have an Order entity that has Items, the > getTotalValue() method is placed in Order. Anything else goes to the business > logic classes. I'm building a system right now with almost all business logic encapsulated in the entities. Most of the entity methods represent state changes (eg. toAccepted(..), toRejected(..), toBilling(..), toBilled(..)) and many of those methods either create related entities or call state change methods on related entities. This kind of encapsulation is exactly what OO was all about before EJB 1 and 2 came along and stuffed us back into a procedural world with an anaemic domain model ( http://martinfowler.com/bliki/AnemicDomainModel.html ). The total effect is like a myriad of state machines interacting with each other, just like the real world, and so far I'm really liking it. > >> Would not this approach represent a net >> lost of flexibilty (because of a lack of "loose coupling")? > > IMHO, yes. If your entities represent the real world entities and the developer can clearly see they implement the same behaviours as the real world entities then it seems to me that it is the "right" coupling! > >> 4) Is there any good tutorial or any good working demo regarding the use >> of Hibernate and/or Jpa with Tapestry5? At the moment I'm studying/using >> the following tutorials and demos/apps. > > http://tapestry.apache.org/tapestry5.1/tapestry-hibernate/userguide.html > http://tapestry.apache.org/tapestry5.1/tapestry-hibernate-core/conf.html > > -- > Thiago H. de Paula Figueiredo > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and > instructor > Owner, software architect and developer, Ars Machina Tecnologia da Informação > Ltda. > http://www.arsmachina.com.br > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org Cheers, Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
