Creation of service level and DAO level (interface + implementation) or only implementation

Question

I am confused by the structure of creating a service level and DAO level: in some examples, I see people creating an implementation of the + interface for the service and DAO, and in other examples I see people creating an implementation only on purpose, when the DAO extends the AbstractDao class, which contains common methods for these DAO, so I don’t understand what to strive for, why choose this or another solution, and what is the best practice (usually used), please advise.

Answer 1

I propose creating interfaces for maintenance and for DAO. Very often, you would like to make fun of a service in unit code tests that use this feature. In addition, Spring, for example, forces you to use interfaces when you use Spring proxies, for example, for transactions. Therefore, you must have an interface for maintenance.

DAO is a more internal part, but I always try to use interfaces to simplify testing.

Answer 2

I prefer the interface + implementation for the following reasons:

• Interfaces become contracts : they tell you what is available for the call, and you will never worry about their implementation, provided that the result is expected.
• You can create a custom implementation of an interface without destroying other implementations of the same interface (this is usually useful when writing unit test). Setting up only the implemented class may result in a larger error than you have not noticed.
• It creates a structure that can be documented.

Implemented subclasses are used to create business / application logic that matches the interface contract.

Answer 3

I performed only the implementation of the service level, did not bother with the interfaces (except when I had to). I probably should figure out how to write interfaces, but so far no problem. I do unit testing just fine, not mocking the level of service.

Also, I don’t have a DAO layer since I am using hibernation and it seemed redundant. Many of my arguments are based on this blog, eloquently written by Bojo .

I think this is quite controversial (be it DAO and hibernate), however I am quite happy with my decision, I am transferring thick domain objects and then just call the hibernation session. Each method at the dao level will literally have only one line (session.persist (mObject) or similar).

One argument I've heard about this is the dao layer, which will make it easier to change / remove orm later. I’m not sure that the time taken to encode the dao level, primarily added to the encoding time of the change, will be less than coding the change without the dao layer on its own. I never had to change ORM technology anywhere I worked, so its a little risk.

Answer 4

From my point of view, when you say Service , you should have interfaces, and if you cannot provide or will not provide it, then you do not have a contract between the service and the consumer and this is not a service anymore, you can call it something still

Answer 5

Interface + implementation is used in order to have free communication. You have the flexibility to change or switch implementations without significant changes to the code.

Think of a scenario where you use Hibernate to save (DAO Layer), and you need to switch to JPA or iBatis or any other ORM, for that matter.

If you use interfaces, you can simply write a JPA-specific implementation and “plug in” it instead of Hibernate. The service code remains the same.

Answer 6

Another argument for the interface model + implementation is that the proxies for the interfaces are supported by Java itself, and creating a proxy for the implementation requires the use of a library such as cglib . And these proxies are needed to support transactions, etc.

Answer 7

Check out my post on the "fastcode" eclipse-spring plugin that generates a service level from your DAO. It works like a charm. create / dao service level for GWT / Spring / Hibernate / PostgreSQL