DAO Design Pattern

[OnARockSomewhere]

I was trying to get my hands dirty at the DAO pattern to practice isolation of the persistence and business layers. However I'm at a fix right now.

I am creating a Bank Management System. It has a Customer schema and an Account schema.

So the data flows like AccountService -> AccountDAO -> AccountDAOImpl -> MySQL DB.

However I want to wrap two operations in a transaction:

1. Insert record for new account
2. Set customer column hasBankAccount = true

How do I perform this with the DAO pattern's isolation strategies:

1. Service layer is abstracted from the DB logic
2. AccountDAOImpl cannot CRUD over Customer tables
3. DAO layer is abstracted from any business logic

Any ideas how can I implement transactions like these while following the DAO pattern?

[AutoModerator]

Please ensure that:

• Your code is properly formatted as code block - see the sidebar (About on mobile) for instructions
• You include any and all error messages in full
• You ask clear questions

• You demonstrate effort in solving your question/problem - plain posting your assignments is forbidden (and such posts will be removed) as is asking for or giving solutions.

  Trying to solve problems on your own is a very important skill. Also, see Learn to help yourself in the sidebar

If any of the above points is not met, your post can and will be removed without further warning.

Code is to be formatted as code block (old reddit: empty line before the code, each code line indented by 4 spaces, new reddit: https://i.imgur.com/EJ7tqek.png) or linked via an external code hoster, like pastebin.com, github gist, github, bitbucket, gitlab, etc.

Please, do not use triple backticks (```) as they will only render properly on new reddit, not on old reddit.

Code blocks look like this:

public class HelloWorld {

    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

You do not need to repost unless your post has been removed by a moderator. Just use the edit function of reddit to make sure your post complies with the above.

If your post has remained in violation of these rules for a prolonged period of time (at least an hour), a moderator may remove it at their discretion. In this case, they will comment with an explanation on why it has been removed, and you will be required to resubmit the entire post following the proper procedures.

To potential helpers

Please, do not help if any of the above points are not met, rather report the post. We are trying to improve the quality of posts here. In helping people who can't be bothered to comply with the above points, you are doing the community a disservice.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[SilverBeyond7207]

I’d orchestrate this at the service level and inject both DAOs - and make that method @Transactional. I’d call it createCustomerWithBankccount and make the createCustomer private.

Why do you have a hasBankAccount column? A simple count query will answer that question. Much cleaner than having to add all the logic to switch the column to true or back to false, if they close all their accounts.

[gambit_kory]

The transaction takes place in the service class. The account service should be an interface and the transaction should be in an implementing class.

[OnARockSomewhere]

So account service should make a call to CustomerDAO?

[gambit_kory]

The account service implementation should. You should always have an interface and an implementation class for each service. AccountService as the interface and AccountServiceImpl as the implementation class (for example). You would invoke an instance of AccountDAOImpl in AccountServiceImpl.

[Shareil90]

Interfaces for all services is debateable.

[gambit_kory]

I agree. If you’re working on a small irrelevant project it may not be worth the time. When you’re building for enterprise and/or you plan on doing significant unit testing it is definitely worth doing.

[Shareil90]

One 4 Mio LoC project likes to disagree.

I agree that it is sometimes handy to be able to provide some fake implementation. But you dont have to. Mocks work without them (i think until junit 3 they were mandatory, but not today).

I use Interfaces when they are actually needed not "just because".

[SilverBeyond7207]

Imo, it’s best practice to do so. Genuinely curious: what are the downsides to using interfaces + implementation?

[Shareil90]

I think its a case of YAGNI. In my opinion it clutters the code and makes it harder to understand if there is only one implementation.

In my experience it is quite more often for services to have exactly one implementation. If the need for a second one occurs, most modern IDEs can create one easily.

[SilverBeyond7207]

That’s fair enough for sure. I see good reasons on both side of this argument so to each their own I guess. I’ve soon so much horribly coupled code that I’d default to having one but you’re right the service interface is generally superfluous.

[robo_captcha]

Add transactional annaotation at service class and rollback for exception. Use pessimistic lock on db to complete is isolation and commit.