J2ee Design Assistance Required...

Question

I am using MVC pattern in my web application. In which i have three layers 1. Control Layer 2. Manager Layer 3. Dao Layer

And i am using DTO's from control layer to manger and then to Dao layer and same as opposite. My question is that what is the main purpose of DTO? Can i use DTO's to map our relational database table or should i go with 'Bean'?

If i use DTO's between layers then how can i represent a database table in object because DTO's among layers can contain properties which are not related to database table.

Answer 1

There is no problem in using DTOs and map them to your database tables. But you'll have to do the mapping by yourself (using JDBC, Spring JDBC, etc).

Another option is to use an ORM to do the mapping of your DTOs to database. You can even create properties that are not mapped to your tables. Take a look at JPA.

The choice between those two options is something personal. The first will be more laborous at first, while the second option have a bigger learning curve. If you are well versed into SQL, I would go with JDBC.

Answer 2

My question is that what is the main purpose of DTO?

The main purpose of a DTO is to transmit data between two layers. It has no real functionality other than to act as a basket for shipping data.

That's why they call it a Data Transfer Object.

Can i use DTO's to map our relational database table or should i go with 'Bean'?

Whether you decide to use JavaBean formatted accessors or your own accessors really doesn't matter with a DTO. Both sides of the transfer must be in agreement; but, if you have a setName(...) setter or a name(...) setter it will not affect functionality.

Although it may not matter in a functionality sense, it is best to stick to established naming conventions for ease of revisiting the code and lack of confusion when training new maintainers. Also, a few libraries might assume you are using bean conventions (or require them). If you are uncertain, best to stick with standard JavaBean conventions, as your new conventions are probably not as tested (or as formal).

If i use DTO's between layers then how can i represent a database table in object because DTO's among layers can contain properties which are not related to database table.

DTOs have nothing to do with database tables. Don't make your DTO look like your database table unless it's the most natural thing to do.

Answer 3

The main purpose of DTO's is to reduce the overhead when transferring data across layers.

If you didnt have a DTO, what you would have is a class containing data as well as logic which would be getting passed across layers. Using DTO's ensures that you pass only what is needed i.e the data across layers.

Definitely, you do have the option of mapping your DTO's to your database tables and having the bean design which more closely represents the domain objects. That is one way of doing it.

Conversely, depending on your database design, your DTO's could be more in line with your actual business entities - just without the logic

Answer 4

My question is that what is the main purpose of DTO?

Like the expansion (Data Transfer Object) implies, DTOs are meant to transfer structured data across various tiers. DTOs enable you to decouple the protocol specific implementations that represent data, so that data from different sources can be abstracted before communication across tiers.

For example, DTOs will allow you to decouple the data present in a HttpServletRequest object from its internal storage, so that you can send the data to a service in the business logic layer. The same applies for DTOs used to abstract the results obtained from a SQL query and residing in a ResultSet object. In short, DTOs allow you to transmit data without holding onto the source - you can forget about the HTTP response and the JDBC connections, while you work on the data.

Can i use DTO's to map our relational database table or should i go with 'Bean'?

You can adopt the second approach of using Beans. In fact, with JPA you do not require your DTOs at all. The JPA managed beans themselves represent data in various tables, and can be de-linked from the database state, so that you can use them for data transmission.

If i use DTO's between layers then how can i represent a database table in object because DTO's among layers can contain properties which are not related to database table.

That depends on how you want to couple the DTO with the database table. It is preferable to have a one-to-one mapping between the DTO and the database table, and choose another DTO for the purpose of transmitting properties not related to the table. After all, DTOs like every other object should have a single responsibility. If the responsibility is to reflect a database table, then it should contain other "irrelevant" properties.

To extend the recommendation of using JPA in this context, it is poor design to have unrelated attributes in a JPA entity, especially when that unrelated attribute should be marked as transient and adds no value to the behavior of the entity.