Writing Hibernate applications in Java

Encoding DataMatrix in Java Writing Hibernate applications

Rethinking data transfer objects The notion that, in an EJB-based application, the web tier shouldn t communicate directly with the domain model, is deeply embedded in J2EE practices and thinking. We doubt that this idea will vanish overnight, and there are certain reasonable arguments in favor of this notion. However, you shouldn t mistake these arguments for the real reason why DTOs became so universally accepted. The DTO pattern originated when the J2EE community observed that the use of fine-grained remote access to entity beans was slow and unscalable. In addition, the entity beans themselves weren t serializable, so some other type of object was needed to package and carry the state of the business objects between tiers. There are now twin justifications for the use of DTOs: first, DTOs implement externalization of data between tiers; second, DTOs enforce separation of the web tier from the business logic tier. Only the second justification applies to us, and the benefit of this separation is questionable when weighed against its cost. We won t tell you to never use DTOs (in other places, we re sometimes less reticent). Instead, we ll list some arguments for and against use of the DTO pattern in an application that uses Hibernate and ask you to carefully weigh these arguments in the context of your own application. It s true that the DTO removes the direct dependency of the view on the domain model. If your project partitions the roles of Java developer and web page designer, this might be of some value. In particular, the DTO lets you flatten domain model associations, transforming the data into a format that is perhaps more convenient for the view. However, in our experience, it s normal for all layers of the application to be highly coupled to the domain model, with or without the use of DTOs. We don t see anything wrong with that, and we suggest that it might be possible to embrace the fact. The first clue that something is wrong with DTOs is that, contrary to their title, they aren t objects at all. DTOs define state without behavior. This is immediately suspect in the context of object-oriented development. Even worse, the state defined by the DTO is often identical to the state defined in the business objects of the domain model the supposed separation achieved by the DTO pattern could also be viewed as mere duplication. The DTO pattern exhibits two of the code smells described in Fowler [1999]: the shotgun change smell, where a small change to some system requirement requires changes to multiple classes; and the parallel class hierarchies smell, where two different class hierarchies contain similar classes in a one-to-one correspondence. The parallel class hierarchy is evident in this case systems that use the DTO pattern

have Item and ItemDTO, User and UserDTO, and so on. The shotgun change smell manifests itself when we add a new property to Item. We must change not only the view and the Item class, but also the ItemDTO and the code that assembles the ItemDTO instance from the properties of an Item (this last piece of code is especially tedious and fragile). Of course, DTOs aren t all bad. The code we just referred to as tedious and fragile the assembler does have some value even in the context of Hibernate. DTO assembly provides you with a convenient point at which to ensure that all data the view will need is fully fetched before returning control to the web tier. If you find yourself wrestling with Hibernate LazyInitializationExceptions in the web tier, one possible solution is to try the DTO pattern, which naturally imposes extra discipline by requiring that all needed data is copied explicitly from the business objects (we don t find that we need this discipline, but your experience may vary). Finally, DTOs may have a place in data transfer between loosely coupled applications (our discussion has focused on their use in data transfer between tiers of the same application). However, JMS or SOAP seems to be better adapted to this problem. We won t use DTOs in the CaveatEmptor application. Instead, the EJB tier session fa ade will return domain model business objects to the web tier. The session fa ade pattern The session fa ade pattern is used in most J2EE applications today and is well known to most Java developers [Marinescu 2002]. A session fa ade is an EJB session bean that acts as the external interface to some business-oriented software component. The use of a session bean lets you take advantage of EJB declarative transactions and security, and provides services that are sufficiently coarse-grained that you avoid the latency of many fine-grained interprocess calls. We won t spend much time discussing this pattern, since it s well understood and noncontroversial. Instead, we ll demonstrate how our previous action example can be rewritten using a session fa ade. We make two major changes to our code from the previous section. First, we change the HibernateUtil class so that the Hibernate SessionFactory is kept in the JNDI registry rather than in a static variable. There s no especially compelling reason for this, apart from consistency with how other similar objects (such as the JTA UserTransaction) are handled in an EJB environment. We have to change the static initializer of the HibernateUtil class and remove the static sessionFactory variable: