-1

I'm having a problem figuring out how to handle the interaction between entities on an application using JDBC. Previously I've used Hibernate and that wasn't a real issue because almost everything was solved either automatically or via annotations. Now, using JDBC there's not such magic.

Lets say I have this classes:

class A{
    private String name;
    private List<B> bs;
    private C c;
}

class AService{
    private ADao aDao;
    void save(A a){
        aDao.persist(a);
    }
}

class ADao{
    void persist(A a){
        //open connection and autocommit false
        //persist C
        //persist B's
        //persist A
        //commit
    }
}

B and C have their respective DAO and Services.
Now, as far as I know, you shouldn't mix DAO's with each other... meaning I shouldn't use in ADao the BDao and/or CDao, just their services.

If this is true, how am I suppose to achieve the desired behaviour? That I can, transactionally, persist multiple entities? Services shouldn't know anything about connection or whatsoever... those are detail implementations that I cannot propagate to the business layer.

So far I haven't found anything online... all the examples are with a single entity, and the only other solution I could come up with was to simply duplicate the code on my other DAO's.

I'd really appreciate any help you can provide, as well as books or good material to read about this. I've found some books about jdbc.. but quite frankly they aren't that good... some of them even propagate the DAO to the presentation layer.. :/

CodeForFun
  • 1

2 Answers2

0

There is no such practice that DAO cannot handle more than one entity. If the DAO was supposed to handle one and one entity then it should accept only one entity, not a nested tree of entities as in your example.

So you have two options.

  1. Decouple A, B, C at the DAO layer. One DAO for each one of them. You already have seen example of persisting one bean. The service layer takes care of orchestrating the persistence of all the beans by calling each DAO as needed. It also takes care of maintaining the relationships. Service layer also wraps all the calls in a transaction.

  2. If the entities A, B and C are closely related, have the entities as you have now. Have one DAO which takes care of A, B and C together. What ever was being done in the service layer in option 1 can be pushed to DAO layer.

Unless your project includes very few entities or you are just playing with jdbc, I would recommend using something like JPA/Hibernate. I know JPA is a pain but plain jdbc will be a nightmare.

gagan singh
  • 1,591
  • 1
  • 7
  • 12
-1

Are you open to using EJB's? They kinda handle the business layer logic well (as in DB START .. ejb function .. DB COMMIT). I know they are out of fashion, but personally I find them to have a place.

Transactions are a business layer problem, not a DAO/data layer problem.

bowzerfood
  • 29
  • 4
  • Hi, I don't want to use a framework/library to solve a design problem. I'd rather learn how to solve it properly. Regarding your last statement, could you please provide a book, link or example to educate myself about how to solve this problem? – CodeForFun Jun 11 '18 at 21:07
  • EJB's are a standard part of Java (Jave EE, not Java SE). You already have the capability to use them in your JDK without adding a library. They handle transactions for you. A good start is https://docs.oracle.com/javaee/6/tutorial/doc/gijsz.html or https://stackoverflow.com/questions/12872683/what-is-an-ejb-and-what-does-it-do. – bowzerfood Jun 11 '18 at 21:21
  • Still, its not an answer to my question. Thank you anyway. – CodeForFun Jun 12 '18 at 15:18
  • Can you please elaborate on why it is not an answer? I am kinda new here and have gotten a surprising amount of down votes so I want to do better. – bowzerfood Jun 14 '18 at 12:56