Data access layer – DTO, DAO

http://rlacovara.blogspot.in/2009/02/high-performance-data-access-layer.html

http://rlacovara.blogspot.in/2009/02/high-performance-data-access-layer_25.html

http://dev.mysql.com/doc/refman/5.1/en/connector-net-tutorials-entity-framework-winform-data-source.html

The ubiquitous data-transfer object (DTO) pattern provides a way of packaging together the data that the view will need. A DTO is a class that holds the state of a particular entity; you can think of a DTO as a JavaBean or POJO without any business methods. DTOs are required in
an entity bean environment, since entity beans aren’t serializable and can’t be transported across tiers. In our case, we can easily make our POJOs serializable, so we naturally find ourselves questioning the need for DTOs.

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 Designing layered applications 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 Item- DTO instance from the properties of an Item (this last piece of code is especially tedious and fragile).

From the book – “Hibernate in action”

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: