DAO Design Pattern and Servlets

Question

I am reading about the DAO design pattern on Oracle's website and I'm trying to understand the below image in the context of using JSP's, Servlets, plain java objects, and the MVC pattern. In my case would the BusinessObject be my servlet and the TransferObject be my java class with only properties, mutators, and accessors (DTO)?

For example, if I had this code in a servlet (controller)

DTO.setFirstName(request.getParameter("firstName"));
DTO.setLastName(request.getParameter("lastName"));
DAO.save(DTO);

_{(source: sun.com)}

score 3 · Accepted Answer · answered Dec 18 '11 at 09:54

3

Almost. Between the controller, which handles presentation logic, and the DAO, which handles Data access logic, there should be a business layer, containing the business objects.

The main responsibilities of these business objects are

to provide business services to the controllers. They are a facade
to encapsulate the business logic of the application
to demarcate transacations
to use one or several DAOs to get, find and persist objects.

This layer is very important because you want to be able to perform several operations on your database within a single transaction. And it should not be the responsibility of the web controller to handle this. Moreover, the same business services could be used by other clients than the web controllers (Swing client, batch, etc.)

Business objects are typically implemented using session EJBs, or Spring services.

They're also useful to be able to

unit test the controller by mocking the business objects
unit test the business logic by mocking the DAOs

answered Dec 18 '11 at 09:54

JB Nizet

678,734
91
1,224
1,255

So the servlets (or whatever) would be using those business objects to easily perform coarse grained business actions such as "new reservation" or "cancel booking"? – cherouvim Dec 18 '11 at 10:01
Exactly. And they don't care whether the new reservation involves one, three of 4 different database accesses, or triggers the post of a message in a JMS queue. That's the business layer's... business. – JB Nizet Dec 18 '11 at 10:04
That makes sense. Do you think that this layering approach is OK to apply even to small web based projects? By small I mean like a login, logout and 5 CRUD use cases. – cherouvim Dec 18 '11 at 10:07
Yes, it doesn't hurt. If I was forced to "sacrifice" a layer, it would be the DAO layer, not the service layer. And I would only do it if using an ORM (JPA, Hibernate) and if the DAOs are trivial to implement. – JB Nizet Dec 18 '11 at 10:14
@JBNizet I'm in a position where I can't use frameworks such as Spring or Hibernate, but this was incredibly helpful. – Robert Dec 18 '11 at 10:17
Thanks for the info. If the application has 100 user actions (of the form create user, delete user, edit user etc) does that mean that we'll have 100 controller actions delegating to 100 business layer methods? – cherouvim Dec 18 '11 at 10:23
Yes, more or less. Some services might be common to several controller actions (exemple: createOrUpdateUser()). Some controller actions might not need any service (wizard form, for example, which only persists at the end of the wizard). And some services might be needed for several actions/pages (get list of countries to display in a select box, etc.) – JB Nizet Dec 18 '11 at 10:32
Great. And is it the case that for simple CRUD apps with 1 database most of those business layer methods would just include a single DAO call, possibly wrapped with some trasaction handling code? – cherouvim Dec 18 '11 at 10:37
Yes, probably. It depends on what API the DAOs use (pure JDBC, JPA, etc.) and how they are designed. Creating an order might involve calling the product DAO for each product references in the order, the calling the order DAO, then calling the order-item DAO for each item in the order. If most of you use-cases are much simpler, then you're lucky. The business logic will be easy to implement. – JB Nizet Dec 18 '11 at 10:50

score 0 · Answer 2 · answered Dec 18 '11 at 09:39

0

Yes, BusinessObject looks like a C (Controller) of the MVC.

answered Dec 18 '11 at 09:39

cherouvim

31,725
15
104
153

Is the "TransferObject" the same as DTO or class with just properties, getters, and setters? – Robert Dec 18 '11 at 09:44
Yes. DTO = Data Transfer Object. It used to be useful ages ago but nowadays you can most probably pass real persistent objects through all layers of the application. – cherouvim Dec 18 '11 at 09:50
When you say "real persistent objects" what are you referring to? An ORM Framework like Hibernate? – Robert Dec 18 '11 at 09:53
Yes. Anything that allows you to persist your objects and does it in a transparent way so your object remain "lightweight" and not coupled to the framework. The most common is Hibernate. – cherouvim Dec 18 '11 at 09:57

score 0 · Answer 3 · answered Dec 18 '11 at 09:53

The whole DAO pattern is part of the Model layer in MVC, in which the BussinessObject offers the Model interface and the DAO and DTO objects part of the pattern implementation.

Your servlet would be (in) the Controller layer and the class that you use to render the HTML (or other format) to be sent to the client would be (in) the View layer.

The size and complexity of your web application determines wether the layers can be built from just one class or not.

In answer to your coment, the DTO (we call it data-holder objects) only consist of attributes, getters/setters, cleanup and validation methods. They function as a separation of concerns between storage / transfer and the implementation of bussiness logic.

DAO Design Pattern and Servlets

3 Answers3

Linked