So lets say we have a couple of entities we want to persist using DAO objects. So we implement the right interface so we end up with
class JdbcUserDao implements UserDao{
//...
}
class JdbcAddressDao implements AddressDao{
//...
}
So if I want to be able to switch persistance implementations from JDBC to JPA (for example) and vice versa, I'd need to have JPAUserDao and JPAAddressDao... Meaning if I had 20 entities, and decided to switch implementations(using DI container), I'd have to switch every Jdbc implementation with JPA in code.
Now it could be that I misunderstood how DAO works, but... If I just had
class JdbcDaoImpl implements UserDao,AddressDao{
//...
}
I'd then have all the JDBC implementations in one class, and switching implementations would be a piece of cake. Also, DaoImpl count is equal to number of Dao interfaces. Why not just group them by implementation (jdbc, JTA, JPA...) and have everything under one class?
Thanks in advance.
Having a single class implement every DAO interface in your entire application would be a rather bad design.
A more typical pattern is to have a BaseDAO interface (also often called GenericDAO) and have a JPABaseDAO, JDBCBaseDAO etc. These base classes will contain methods like find/get/read, save/store/persist, update/modify and delete/remove/purge.
Specific DAO interfaces like UserDAO then inherit from BaseDAO and concrete implementations like JPAUserDAO extends from JPABaseDAO.
A BaseDAO interface could look like this:
public interface BaseDAO <T> {
T getByID(Long ID);
T save(T type);
T update(T type);
void delete(T type);
}
And a UserDAO interface:
public interface UserDAO extends BaseDAO<User> {
List<User> getAllAuthorized();
}
Bare bones example of a JPABaseDAO implementing this interface:
#Stateless
public class JPABaseDAO<T> implements BaseDAO<T> {
#PersistenceContext
private EntityManager entityManager;
private final Class<T> entityType;
#SuppressWarnings("unchecked")
public JPABaseDAO() {
this.entityType = ((Class<T>) ((ParameterizedType) getClass().getGenericSuperclass()).getActualTypeArguments()[0]);
}
#Override
public T getByID(Long ID) {
return entityManager.find(entityType, ID);
}
#Override
public T save(T type) {
return entityManager.persist(type);
}
#Override
public T update(T type) {
return entityManager.merge(type);
}
#Override
public void delete(T type) {
entityManager.remove(entityManager.contains(type) ? type : entityManager.merge(type));
}
}
And some sample UserDAO implementation that would inherit from it:
#Stateless
public class JPAUserDAO extends JPABaseDAO<User> implements UserDAO {
#PersistenceContext
private EntityManager entityManager;
#Override
public List<User> getAllAuthorized() {
return entityManager.createNamedQuery("User.getAllAuthorized", User.class)
.getResultList();
}
}
In practice the base class can often do some other things transparently, for instance checking if an entity implements some kind of Auditable interface, and automatically setting the date and user that modified it, etc.
When using EJB to implement your DAOs, one strategy to change implementations would be to put all JDBC implementations in one package and all JPA implementations in the other. Then just include only one implementation package in your build.
The whole point of Dependency Injection is to make switching between implementation easier and to decouple the user from the provider. Hence all DI frameworks provide some way to "group" several implementations (here your JDBC-group and your JPA-group) and switch them in one place.
Also: Usually the number of consumers (in your case: some business logic working on users and addresses) is usually higher than the number of DAOs the DI framework will uncouple most of the stuff for you anyway. Assume: 50 business beans, two interfaces and two implementations for each interface (4 total): even basic DI will take care for the 50. Using grouping will halve that remaining rest for you.
There are definitely possibilities to implement the DAO pattern in a widely technology agnostic way such that switching persistence technology or even mixing multiple technologies becomes feasible. This article presents one implementation scheme including source code on github.
http://codeblock.engio.net/?p=180
Related
I have received an assigned with some empty skeleton files. Amongst these files there's two interfaces which I can't seem to understand. This one:
/*
* Interface defining abstract CRUD methods for each of your Controllers.
*/
public interface CrudController<T> {
List<T> readAll();
T readyById();
T create();
T update();
int delete();
}
and this one:
/*
* Interface defining abstract CRUD methods for each of your Data Access Objects.
* Implementation of this will involve JDBC.
*/
public interface DAO<T> {
List<T> readAll();
T readById(Long id);
T readLatest();
T create(T t);
T update(T t);
int delete(Long id);
T modelFromResultSet(ResultSet resultSet) throws SQLException;
}
What I don't understand is why there is a need for both of these. The work is supposed to be related to managing a mySql schema using Java. What is the difference between a CrudController and a DAO class, I though both of these were used for Database persistence and reading.
Traditionally the separation exist to separate interactions with the database/persistence and business logic. The difference between the two in this case is the CrudController would handle the business/application logic and the dao would handle the persistence logic. For example, in the scope of a REST application, the controller is receiving the request and calling a implementation of the dao (or a service which calls the dao) to perform database actions.
By implementing the DAO design pattern we separate the part that communicates with the database from the rest of the application.
The DAO pattern defines the CRUD (create,read,update,delete) operations for all the entities. We can completely separate the persistence layer by adding named/native queries. These will be used for the entity itself.
public interface DAO<T,E extends Serializable>{
public T save(T object);
public Boolean delete(T object);
public T update(T object);
public T find(E id);
}
The interface for the DAO defines only the operations specified in the implementation.
So CRUD just an abbreviation but DAO is a design pattern.
LINK
I'm learning how to extend Spring's CrudRepository interface to create a repository for an entity. But I'm having trouble implementing more complicated queries that use values that aren't hard-coded. Here's a contrived example. The HQL is not valid, but it shows what I'm trying to do:
import mypackage.DogTypeEnum;
public interface myRepository extends CrudRepository<Dog, Integer> {
int oldAge = 10; // years - old for a dog
#Query(SELECT dog From Dog dog WHERE dog.age > oldAge and dog.type = DogTypeEnum.poodle
public List<Dog> findOldPoodles()
}
So in the above example, I'm trying to query for all dogs of type poodle that are over a certain age threshold. I don't want to hard code either poodle or the value 10 because these values that will be used elsewhere in the code as well and I want to avoid duplication. I don't want to require the user to pass those values in as parameters either.
Is there a way to do this?
You could create a Interface that extend your repository as like this:
//Only complex querys
public interface MyRepositoryCustom {
List<Dog> findOldPoodles()
}
// Your Repository must extends to MyRepositoryCustom
public interface MyRepository extends CrudRepository<Dog, Integer>, MyRepositoryCustom {
// Declare query methods
}
//More complex query
public class MyRepositoryImpl implements MyRepositoryCustom {
#PersistenceContext
private EntityManager em;
public List<Dog> findOldPoodles() {
Query query = em.createQuery("SELECT dog From Dog dog WHERE dog.age > :oldAge and dog.type = :type");
query.setParameter("oldAge",10);
query.setParameter("type",DogTypeEnum.poodle.name);
return query.getResultList();
}
}
Remember all java class starts with a Upper Case letter.
This link can help you: Spring repositories
In my case I'll never have this problem, if you structure your project as the next package architecture shows, you won't have this problem:
View (Angular, JSP, JSF...) -- APP
Controller -- APP
Services -- Main Core
DAO -- Main Core
Entities -- Main Core
This way you make more modular, escalable, maintainable and comprehensive application.
It doesn't matter what technology you use in your view, you just have to invoque the correct method on the service.
In here, on the services package you could have a service for example:
#Service
public class ServiceDog extends Serializable {
#Autowired
private MyRepository myRepository;
int oldAge = 10;
public List<Dog> findOldPoodles() throws ServicioException {
return myRepository.findAllByAgeGreaterThanAndType(oldAge, DogTypeEnum.poodle);
}
}
Now you could use all the advantage you get from using spring-data-jpa reference or make a more simple JPQL Query.
This is a simple example but this way you make sure that each DAO speak with only one entity (It will only have the methods needed for this entity like save, delete.. with no dependencies with other DAOs), and the service are the ones on calling the different DAOs and make the necessary actions on them.
Hope this helps.
I'm building a Spring Boot application containing more than 10 domain classes which need to be persisted in a SQL database.
The problem is that I need to create an interface for every single domain class, so something like this for each one:
public interface BehandelaarRepo extends CrudRepository<BehandelCentrum, Long> {
}
Is there any way to decrease the number of repositories by using some kind of design pattern or whatever? Any suggestions?
You can actually make it some easier for yourself by using generics the same way Spring Data JPA does it:
public interface JpaRepository<T extends Serializable, ID extends Serializable> {
public <S extends T> S save(S object);
}
The trick is that you can use all subclasses, and you're getting that class back as well. I always create one superclass, so I get rid of my ID generic:
#MappedSuperclass
public class JpaObject {
#Id
#GeneratedValue
private Long id;
(.... created, last updated, general stuff here....)
}
I create my #Entity classes as a subclass from this JpaObject.
Second step: create my super interface for future usage of special queries:
#NoRepositoryBean
public interface Dao<T extends JpaObject> extends JpaRepository<T, Long> {
}
Next step: the generic Dao which looks some stupid and remains empty at all times
#Repository
public interface GenericDao extends Dao<JpaObject> {
}
Now have a sharp look at that save method in CrudRepository / JpaRepository:
public <S extends T> S save(S object);
Any object extending JpaObject (S extends JpaObject) now can be given as a parameter to all methods, and the returntype is the same class as your parameter.
(Aziz, als het handiger is, kan het ook in het Nederlands uitgelegd worden :P Groet uit Zwolle)
Well, I had a similar problem. I resolved it by creating new layer, namely
RepositoryManager (or ModelService) singleton that had all the repo interfaces and methods that used them.
If you want you can implement generic save method (then call that class ModelService) that resolves model types through reflection and chooses the corresponding repository.
It was also handy for decoupling cache implementation (I used spring cache).
My project manager wants me to use DAO/DTO objects to access and retrieve data from database. Project is written in Java SE without using any framework or ORM. His arguments is to make code more testable and to improve code design. Does it make sense?
How about initializing DAO object? Should it be initialized when the instance of class having DAO field is created:
private PersonDao personDao = new PersonDaoImpl();
or rather initialized when it is necessary?
public class A {
private PersonDao person;
public List<Person> findAll() {
person = new PersonDaoImpl();
return person.getAll();
}
}
It allows to mock this interface easily, but is it right to the DAO pattern usage convention?
The Data Access Object is basically an object or an interface that provides access to an underlying database or any other persistence storage.
That definition from: http://en.wikipedia.org/wiki/Data_access_object
Maybe a simple example can help you understand the concept:
Let's say we have an entity to represent an employee:
public class Employee {
private int id;
private String name;
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
The employee entities will be persisted into a corresponding Employee table in a database. A simple DAO interface to handle the database operation required to manipulate an employee entity will be like:
interface EmployeeDAO {
List<Employee> findAll();
List<Employee> findById();
List<Employee> findByName();
boolean insertEmployee(Employee employee);
boolean updateEmployee(Employee employee);
boolean deleteEmployee(Employee employee);
}
Next we have to provide a concrete implementation for that interface to deal with SQL server, and another to deal with flat files, etc...
Hope that helps
To maximimze the benefits of testability and separation of concerns you should introduce the concept of Inversion of Control (IoC). When applying IoC to the management of object lifecycles the term Dependency Injection is used. What this means is that your class A should be completely agnostic of which implementation is instantiated when.
In order to achieve this you need an extra component to bootstrap your application and inject all classes with the correct implementations.
You could set up your dependency-receiving class like this (setter injection, you can also use constructors)
public class PersonServiceImpl implements PersonService {
private PersonDao personDao;
public List<Person> findAll() {
return personDao.getAll();
}
public setPersonDaoA(PersonDao personDao) {
this.personDao = personDao;
}
}
And a component to do the dependency injection:
public class ApplicationContext {
private PersonService personService;
private PersonDao personDao ;
public PersonService getPersonService() {
if (personService == null) {
personService= new PersonServiceImpl();
personService.setPersonDao(getPersonDao());
}
return personService;
}
public PersonDao getPersonDao() {
if (personDao == null) {
personDao = new PersonDaoIml();
}
return personDao ;
}
}
Then application startup would involve this:
public class Main {
public static void main(String[] args) {
ApplicationContext ctx = new ApplicationContext();
PersonService personService = ctx.getPersonService();
personService.findAll();
}
}
As you can see, the ApplicationContext encapsulates knowlegde about:
which implementations to use
in which order to set a chain of dependencies
which dependencies are already instantiated or not
The PersonServiceImpl class is now completely testable and all concerns regarding object lifecycle management have been extracted from it.
In real life this if often done using a framework like Spring or CDI (which is becoming more and more popular recently). But in your situation, starting off with an approach like above might be a good first step. It will reap the immediate benefits mentioned by your project manager without incurring the overhead of introducing Spring, possibly changing your build too and having to learn how that works (e.g. with an XML context, source code context and/or annotations).
Introducing Spring at a later stage will be easy because all classes are already prepared for Dependency Injection. Just keep in mind that your factory (ApplicationContext in my example) should not take on any extra responsibilities like configuration management.
Also keep in mind that the above example of ApplicationContext is not a singleton. You yourself should make sure only one instance of it is created when your application starts, and all injections are handled by it. Creating duplicate instances could cause confusing bugs.
The DAO pattern is not an "enterprise" pattern. It's mostly seen in "enterprise" applications, but you can absolutely use in a an application written in SE only.
It's not because you're writing an SE application that you don't have to test, so indeed, your code will be more testable using the DAO pattern and IOC rather than using straight JDBC in your application.
The way you're implementing your class using the DAO is problematic because your class cannot be tested properly because of the tight coupling between your class A and your DAO implementation. You're better off using the IOC pattern as well with a framework like Guice or Dagger (both designed with SE in mind).
For a code example, look at slnowak's answer.
The way you are using it, it is still tightly coupled with your class A.
You should provide your DAO as a dependency, using constructor or setter. Probably the most preferable way is to use some kind of Inversion of Control (for example dependency injection framework).
Your class A should be something like:
public class A {
private PersonDao personDao;
// possibly an #Inject annotation
public A(PersonDao personDao) {
this.personDao = personDao;
}
public List<Person> findAll() {
return personDao.getAll();
}
}
And actually, I would consider it an antipattern this way. It depends on how you are about to use your class A.
If it contains different business logic - fine.
If it just dispatches a call to DAO (I don't like this name, maybe use Repository instead ;)) then it is just unnecessary layer of abstraction.
Another thing - you mentioned DTO. So a Person class is just a DTO in this case? Here we could have another antipattern. DTO is fine for example if you need to transform your business object(s) into something that is visible on the screen. Or to separate perstistence model from business model.
What I'm trying to say is: don't make a Person class just a data structure. Give it some behaviour.
Is it typical to name DAOs in the following way:
UserDAO - interface
UserDAOImpl - implements UserDAO
I am wondering if its standard to use the suffix 'Impl' for the implementation or if something more meaningful is the best practice. Thanks.
That is generally what I use. Sometimes the Default prefix like DefaultUserDAO might make more sense if you're creating an interface that you expect others to implement but you're providing the reference implementation.
Most of the time I feel those two can be used interchangeably but in some situations one provides a little more clarity than the other.
There are two conventions that I've seen:
FooDao for the interface and FooDaoImpl for the implementation
IFooDao for the interface and FooDao for the implementation
The former has its roots in CORBA; the latter is a Microsoft COM/.NET convention. (Thanks to Pascal for the correction.)
"Don't Repeat the DAO" is a fine idea. I personally think that article is more complex than it needs to be. There's a way to do it without reflection in finders that I happen to prefer. If you use Hibernate, query by example can be a great way to do it simply. The interface would look more like this:
package persistence;
import java.io.Serializable;
import java.util.List;
public interface GenericDao<T, K extends Serializable>
{
T find(K id);
List<T> find();
List<T> find(T example);
List<T> find(String queryName, String [] paramNames, Object [] bindValues);
K save(T instance);
void update(T instance);
void delete(T instance);
}
First of all - you may not really need a DAO class for each of your classes. Don't repeat the DAO! article explains what is a generic DAO. Wondering how to name boilerplate code is not productive.
Now, when you have a generic DAO, you could go for:
DAO (interface)
SessionDAO and EntityManagerDAO - for using either Session or EntityManager
And, of course, use the DAO only by interface. You can easily switch between implementations.
(I actually prefer it lowercased - Dao, although it's an abbreviation; and the Impl suffix)
I've been also fan of the GenericDao and GenericDaoImpl -convention with some support from generic helper classes, should the save or delete require extra actions for some persistent classes:
public interface PersistListener<T> {
void onPersist(T item);
}
Similar constructs can be used also for deletion. This is especially useful if you need some kind of event log to write each activity to and you don't want to use AOP for that.
My GenericDaoImpl would look something like this:
public class GenericDaoImpl<T> extends HibernateTemplate {
public void setPersistListeners(List<PersistListener> listeners) {
this.persistListeners = new GenericInterfaceHandler( listeners,
PersistListener.class );
}
// hibernate updates the key to the object itself
public T save(T item) {
getSession().save( item );
List<PersistListener<T>> listeners = this.persistListeners.getAll( item );
for ( PersistListener<T> listener : listeners )
listener.persist( item );
}
// ...
}
What the persistListener in the above example will do is to find a PersistListener with generic class matching to that of the class given as a parameter. It such is found, then call is delegated to the proper listener(s). My GenericInterfaceHandler also can be used to return only most specific handler or only handler for the given class if present.
If you are interested, I could also post the GenericInterfaceHandler implementation as it's quite powerful construct on many occasions.