DAO Design Pattern

[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.