I am aware of factory and abstract factory methods, but I want to create a DAO factory pattern in Java.
I have checked this link but it is difficult for me to understand.
Can anyone explain it with the help of an example?
Edit: Here is an example of DAO pattern as I understood it:
public interface UserDAO { public void insert(User user); public void update(User user); public void delete(int userId); }
Implementation:
public class UserDAOImpl implements UserDAO { @Override public void delete(int userId) { // delete user from user table } @Override public User[] findAll() { // get a list of all users from user table return null; } @Override public User findByKey(int userId) { // get a user information if we supply unique userid return null; } @Override public void insert(User user) { // insert user into user table } @Override public void update(User user) { // update user information in user table } }
Factory:
public class UserDAOFactory { public static UserDAO getUserDAO(String type) { if (type.equalsIgnoreCase("jdbc")) { return new UserDAOImpl(); } else { return new UserDAOImpl(); } } }
Client side code:
User user=new User(); user.setName("Jinoy P George"); user.setDesignation("Programmer"); user.setAge(35); //get a reference to UserDAO object UserDAO userDAO=UserDAOFactory.getUserDAO("jdbc"); //call insert method by passing user object userDAO.insert(user);
Is this dao pattern correct?
Where should I open connection and close it?
The DAO factory is responsible for determining how to create the DAO object. This may involve implementation-specific DAO factories responsible for creating the DAO objects.
DAO stands for "Data Access Object". It's an interface-based class that handles all your CRUD operations with a relational database for a particular object.
The Data Access Object (DAO) pattern is a structural pattern that allows us to isolate the application/business layer from the persistence layer (usually a relational database but could be any other persistence mechanism) using an abstract API.
Benefits of using DAO design pattern. DAO design pattern also keeps coupling low between different parts of an application. By using DAO design pattern your View Layer is completely independent of DAO layer and only Service layer has the dependency on it which is also abstracted by using DAO interface.
DAO stands for "Data Access Object". It's an interface-based class that handles all your CRUD operations with a relational database for a particular object. Here's an example that uses generics:
package persistence; public interface GenericDao<K extends Serializable, T> { public T find(K id); public List<T> find(); public K save(T value); public void update(T value); public void delete(T value); }
Think of a factory as a "virtual constructor": its creation method returns an interface type, but you can ask it to create any number of different implementations as needed.
Probably what you don't understand is how the code works? It seems fine.
Just FYI:
What is defined as UserDAOImpl can be better understood if you consider naming it as UserDAOMySQLImpl and another new one as UserDAOMSSQLImpl, and so on for each database access you may need.
In each of those you should handle the connections and add other things like private functions for that specific database server configuration it may need and not forcibly needed to be declared in the interface (UserDAO) but as minimum you must always implement all the methods defined in the interface, then in the Factory (UserDAOFactory) conditions you could have something like this:
`
public class UserDAOFactory{ public static UserDAO getUserDAO(String type){ if (type.equalsIgnoreCase("mysql")){ return new UserDAOMySQLImpl(); }else{ return new UserDAOMSSQLImpl(); } } }
A little clearer?
Then, in the client side instead of a hardcoded line like:
UserDAO userDAO=UserDAOFactory.getUserDAO("jdbc");
You could have a properties file to be able to switch between DAOs dynamically, having retrieved that string from the properties file you can simply do:
UserDAO userDAO=UserDAOFactory.getUserDAO(myStringFromPropertiesFile);
myStringFromPropertiesFile would contain "mysql" or "mssql" according to the definition in your properties file.
Hope this helps!
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With