0

I have a business class, which calls the DAOimpl class which implements DAO interface, now how is this reducing coupling. DAO is used to reduce coupling with persistence logic. WHat should we do to reduce coupling between DAO and business logic.

dexterousashish
  • 373
  • 1
  • 4
  • 18
  • Code oriented to interfaces instead of class implementation. – Luiggi Mendoza Sep 24 '13 at 19:41
  • @Esko they can indeed. I confronted a use case where the main problem was accessing to the data too many times, so the Dao implementation looked up the data in cache and retrieve the query results from the cache instead going to database (as usual). – Luiggi Mendoza Sep 24 '13 at 19:43
  • 3
    DAO pattern is an anachronism with modern ORM. The EntityManager/H-Session/etc is already an abstraction for the relational persistence model. Inserting yet another one is an artifact. – Affe Sep 24 '13 at 19:43
  • 3
    I believe, this question is these days offtopic here and belongs on programmers.se. But ala, if you happen to use Java EE, I just wanted to say, lately with Java EE 5/6, the new JPA API has made the "homegrown" DAO pattern obsolete. JPA is the whole DAO at its own. JPA API is now the interface and Hibernate, EclipseLink, etc are now the concrete implementations which you actually don't need to code on your own but just drop in the classpath (like as you "previously" do with JDBC API and JDBC drivers). See also e.g. http://stackoverflow.com/q/2100115 – BalusC Sep 24 '13 at 19:46
  • @BalusC I wouldn't want to use (for example) the Hibernate classes directly from my business layer. I would still wrap all that behavior in a [`Data Mapper`](http://martinfowler.com/eaaCatalog/dataMapper.html) or DAO. – Sotirios Delimanolis Sep 24 '13 at 19:48
  • 1
    @Soti: when I said Hibernate, I don't mean the "good old" Hibernate for J2EE, but their actual JPA implementation, the `EntityManager`, which they provided since Java EE 5 over 7 years ago. Perhaps it's time to catch up the new things in Java EE? – BalusC Sep 24 '13 at 19:49
  • 1
    @BalusC All the same, I'm not going to write JPQL queries directly in my business code. – Sotirios Delimanolis Sep 24 '13 at 19:50
  • Are you using spring, you can inject DAO layer using spring. – Sachin Thapa Sep 24 '13 at 19:50
  • 1
    @Soti: So, you want to be able to switch between e.g. raw JDBC, old Hibernate, new JPA and whatever (MyBatis?). How does that make sense in a modern Java EE application offering JPA out the box? Note that JPQL is not specific to Hibernate, but just to JPA API. – BalusC Sep 24 '13 at 19:51
  • I for one definitely *do* want to write JPQL in the business class. Hardly anything describes the business logic better than datastore queries. Inserting another layer of indirection just forces you to think up of an ugly long name for each of your queries. – Marko Topolnik Sep 24 '13 at 19:52
  • 2
    @BalusC Say a requirement changes and you can't directly access the database anymore. Instead, you have to use a web service connected to some administration web application. The dao interface would remain unchanged. You would only add a different implementation. Am I missing the point? – Sotirios Delimanolis Sep 24 '13 at 19:55
  • @All Why do you want to add as many additional layers? For more pay? No other reason. I prefer the simplicity of Java EE 6/7 over the complexity acquired as a habit. – Paul Vargas Sep 24 '13 at 20:02
  • 1
    @Soti: a DAO to access a web service? If it runs on same webapp, just inject it directly. Or if it really runs on a different context, change the business service implementation instead of "DAO" implementation. – BalusC Sep 24 '13 at 20:02
  • 1
    @BalusC I think we're saying the same thing, but I might be using the wrong terms. Can you please comment on my answer below? – Sotirios Delimanolis Sep 24 '13 at 20:08
  • Isn't JPA offtopic here? For JPA I recommend using repository pattern instead of directly accessing entitymanager from business classes - it generally makes things easier to test. – Sami Korhonen Sep 24 '13 at 20:34

1 Answers1

4

Your business class wants to interact with other business classes. The interface your DAO provides should only require dependencies on business classes.

For example 

public class Apple extends Fruit {}

and 

public interface AppleDao extends Dao { // can be refactored even more
    public void add(Apple apple) throws FruityException;
}

and an implementation

public class AppleDaoHibernateImpl implements AppleDao {
    @Inject
    private Session session; // Hibernate session or JPA EntityManager, etc. 

    public void add(Apple apple) throws FruitException {
        // do something with session, entityManager, etc.
    }
}

When your business classes use AppleDao, they don't see any SQL, I/O, etc. classes they need to import (depend on). Instead they see only more business (model) classes like Apple and FruityException.

This way you can change your underlying implementation, for example use a web service instead of using a database directly, without changing the interface.

Sotirios Delimanolis
  • 274,122
  • 60
  • 696
  • 724
  • 1
    [**JPA/EJB3 KILLED THE DAO**](http://www.adam-bien.com/roller/abien/entry/jpa_ejb3_killed_the_dao) – Paul Vargas Sep 24 '13 at 19:54
  • @Sotirios If i am writing a code like this in my business class to aceess my DAO public class BUsiness{ AppleDAO appDao= new AppleDAOImpl(); appDAO.add(Apple);} then it wil lead to coupling between the business and the DAO. how to reduce that ? – dexterousashish Sep 24 '13 at 20:35
  • @PaulVargas I disagree with the premise of the article. JPA is something that can be still be abstracted in a DAO. If you know for sure you'll always use JPA forever, that's fine, but the whole point of a DAO is to abstract the details of persistence, and JPA is a persistence detail even though its an interface that abstracts a subset of persistence solutions. – Dev Sep 24 '13 at 20:39