Questions regarding the DAO pattern

[Simon Choi]

Hi,
I've got couple questions when applying the DAO pattern on my current project. Some backgrounds of the project, we are not using any frameworks, everything in the backend is purely servlets, I want to separate the business logic and the data access layer, after doing some research, I think the DAO pattern is the way to go.

1) It seems that DAO and Factory pattern are used together most of the time, if I only have 1 data source which is MySQL and I am very sure that we will not have another one in the future, do I still need to create the MySQLFactory class and get the DAOs through this class? Can the business object directly initiate the DAO object when necessary instead of going through the Factory pattern?

2) When creating the DAO object, people recommend that I should have CRUD (Create, Read, Update, Delete) methods within the DAO class. There are around 10 DAOs (10 tables) need to be created in this project, in most cases, I only need the read functionality, as I'm going to use the DAO to fetch the data from the database and pass it to the business object to do processing, there are 3 tables which I will need to perform insert/update. My question is can I have the Read method only for the DAOs which I only perform fetch, and implement Create, Update for DAOs where I actually need to do insert/update. Is this a bad practice? I just don't see the point to always include all these 4 methods in every DAOs.

Any help is greatly appreciated. Thanks!

Simon C.

[Arun Kumarr]

Simon Choi wrote:Hi,
I've got couple questions when applying the DAO pattern on my current project. Some backgrounds of the project, we are not using any frameworks, everything in the backend is purely servlets, I want to separate the business logic and the data access layer, after doing some research, I think the DAO pattern is the way to go.

1) It seems that DAO and Factory pattern are used together most of the time, if I only have 1 data source which is MySQL and I am very sure that we will not have another one in the future, do I still need to create the MySQLFactory class and get the DAOs through this class? Can the business object directly initiate the DAO object when necessary instead of going through the Factory pattern?

2) When creating the DAO object, people recommend that I should have CRUD (Create, Read, Update, Delete) methods within the DAO class. There are around 10 DAOs (10 tables) need to be created in this project, in most cases, I only need the read functionality, as I'm going to use the DAO to fetch the data from the database and pass it to the business object to do processing, there are 3 tables which I will need to perform insert/update. My question is can I have the Read method only for the DAOs which I only perform fetch, and implement Create, Update for DAOs where I actually need to do insert/update. Is this a bad practice? I just don't see the point to always include all these 4 methods in every DAOs.

Any help is greatly appreciated. Thanks!

Simon C.

Hi Simon, Welcome to Javaranch.

What do you mean backend is servlets? Do you mean from servlets you directly make database calls??
As for your questions, comment in order,

1. DAO pattern has nothing to do with what database you are using or how many schemas you are using. What you seemed to worry is "Data Access Layer" and not "Data access Object". Calling DAO Layer a sub-set of your Data Access layer seems reasonable to me. You need to understand what is a 3-tier architecture and especially the evolution of DAO layer. Factories are just a structural design to produce DAO objects. It can produce anything.

DAO are just wrappers which wrap all database related information which contain simple data access operations. You can choose to have 12 DAOs for a database of 5 tables. It's just logical arrangement of how data is accessed. However the general design is to have one DAO for each table. Nothing stops you from having 3 DAOs for doing all operations related to a single table.

2. You can have a common abstract class and extend it in all your DAO implementations. If you are so particular that you don't want to have extra unimplemented methods, then you can go for 4 interfaces each calling themselves, ReadInterface, WriteInterface, UpdateInterface and DeleteInterface and implement whatever is necessary. No harm.

2 Things I see is needed.
1. Study multi-tier architecture.
2. Evolution of DAL and DAO pattern.

[Simon Choi]

Hi Arun, thanks for the reply and suggestions.

Yes, I just newly joined the team and as far as I know, we have been directly making SQL calls in the servlet, then manipulated the data, and generated the response. This is why I start look into the DAO pattern to separate the Data Access Layer from the business logic.

1. I understand that factory pattern is a structural design that can produce anything, let's say I have 10 tables that include data for users, orders and products. Is it a good practice to have one factory (MySQLDAOFactory) to produce all these 10 DAOs or should I create MySQLUserDAOFactory to produce user DAOs, MySQLOrderDAOFactory to create order DAOs...etc?
Or can I initiate the DAO object directly in my business object? Like UserDAO userDAO = new UserDAOImpl().


2. Thanks for the idea in my 2nd question, I think I will create 4 marker interfaces (DAOCreatable, DAOUpdatable, DAODeletable, DAOReadable), and have the individual DAOImplementation class to implement these 4 interfaces. Since the create method in UserDAO may not have the same signature as the one in OrderDAO.

Below are something that I'm going to have:
UserDAOImpl implements UserDAO, DAOReadable
OrderDAOImpl implements OrderDAO, DAOCreatable, DAOUpdatable, DAOReadable

Will this be a good approach?

3. 1 more question regarding the Transfer Object, does the TO need to reflects the complete entry in the database? Let's say I have a USER table with 20 fields, most of the time the business logic is depended on 5 particular fields only, so I should have a SQL to select that 5 fields in DAO's read method(), so how should I return a TO in this case, construct a TO with that 5 fields only and leave other member variables as default values? That doesn't seem right to me, but I'm not seeing a good approach on that. And also I have to consider in case I need to do a insert, I will need to create a TO with all 20 field values.

4. What is DAL pattern?

Thanks.
Simon

[Arun Kumarr]

Simon Choi wrote:Hi Arun, thanks for the reply and suggestions.

Yes, I just newly joined the team and as far as I know, we have been directly making SQL calls in the servlet, then manipulated the data, and generated the response. This is why I start look into the DAO pattern to separate the Data Access Layer from the business logic.

1. I understand that factory pattern is a structural design that can produce anything, let's say I have 10 tables that include data for users, orders and products. Is it a good practice to have one factory (MySQLDAOFactory) to produce all these 10 DAOs or should I create MySQLUserDAOFactory to produce user DAOs, MySQLOrderDAOFactory to create order DAOs...etc?
Or can I initiate the DAO object directly in my business object? Like UserDAO userDAO = new UserDAOImpl().

-- One factory to produce any type of DAO is good.


2. Thanks for the idea in my 2nd question, I think I will create 4 marker interfaces (DAOCreatable, DAOUpdatable, DAODeletable, DAOReadable), and have the individual DAOImplementation class to implement these 4 interfaces. Since the create method in UserDAO may not have the same signature as the one in OrderDAO.

Below are something that I'm going to have:
UserDAOImpl implements UserDAO, DAOReadable
OrderDAOImpl implements OrderDAO, DAOCreatable, DAOUpdatable, DAOReadable

Will this be a good approach?

-- Yes. It is.

3. 1 more question regarding the Transfer Object, does the TO need to reflects the complete entry in the database? Let's say I have a USER table with 20 fields, most of the time the business logic is depended on 5 particular fields only, so I should have a SQL to select that 5 fields in DAO's read method(), so how should I return a TO in this case, construct a TO with that 5 fields only and leave other member variables as default values? That doesn't seem right to me, but I'm not seeing a good approach on that. And also I have to consider in case I need to do a insert, I will need to create a TO with all 20 field values.

-- You are right. Keep the Data Transfer Objects as light as possible and at the same time carry all necessary information which are required by the Business layer or in some cases UI Layer. You don't want to come back again all the way down from your screens for more detail.

4. What is DAL pattern?

-- DAL is just one of the Tiers in an N-tier architecture. Data can come from any sources, it could be database, file system or it could be another system supplying data. The Data Access layer, abstracts them all and takes care of only getting data from various sources and providing it to the caller of the layer. Almost any code written in a data access layer is centered around obtaining data from various sources. If all your data exists in a database then your data access layer will have DAOs talking to various tables, running SQLs and providing DTOs to the caller. It's just part of an architecture.

Thanks.
Simon

[Simon Choi]

Thanks Arun!

[Arun Kumarr]

Arun Kumarr wrote:

Simon Choi wrote:....

Below are something that I'm going to have:
UserDAOImpl implements UserDAO, DAOReadable
OrderDAOImpl implements OrderDAO, DAOCreatable, DAOUpdatable, DAOReadable
.......

For this I'd rather say have your UserDAO extend DAOReadable and your OrderDAO extend DAOCreatable, DAOUpdatable, DAOReadable because the caller of the UserDAOImpl is going view the UserDAOImpl object via the UserDAO Interface and when they check the methods, they see all the methods from both from UserDAO and from DAOReadable.