7

I am confused about the structure of creating service layer and DAO layer: in some examples I see some people creating interface+implementation for both service and DAO and in other examples I see people creating implementation only specially when the DAOs extends an AbstractDao class that contains generic methods for those DAOs, so I am confused about what to go for, why to go for this solution or the other one, and what is the best practise (commonly used) please advise.

Cœur
  • 37,241
  • 25
  • 195
  • 267
fresh_dev
  • 6,694
  • 23
  • 67
  • 95

7 Answers7

6

I suggest to create interfaces for service and for DAO. Very often you would like to mock service in unit tests of code, that use this serice. Also Spring, for example, forces you to use interfaces when you are using some Spring proxies for example for transactions. So you should have an interface for service.

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

dbf
  • 6,399
  • 2
  • 38
  • 65
  • please can you give more details further with example and references, because i need to convenience some colleague. – fresh_dev Nov 14 '11 at 12:12
2

I prefer interface + implementations for the following reasons:

  • Interfaces becomes contracts: they tell you what is available to call, and you never worry about the implementation thereof, provided that the result is expected.
  • You can create customizable implementation of the interface without breaking other implementations of the same interface (generally useful when writing unit test). Customizing an implemented only class can bring more error than you don't notice easily.
  • It creates a framework that can be documented.

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

Buhake Sindi
  • 87,898
  • 29
  • 167
  • 228
  • what about if the DAOs extends a BasicDao that contains generic methods for CRUD operations, will then interface be important, since i can override the generic methods in the BasicDao ? – fresh_dev Nov 14 '11 at 12:14
  • You can override the method but the method signature will be the same. Essentially, the user won't know that the method is subclassed but is only interested in the data returned from the Service/DAO. – Buhake Sindi Nov 14 '11 at 12:16
  • so if used a generic AbstractDao class with the DAOs, it's better to use interface too. – fresh_dev Nov 14 '11 at 12:19
  • Preferably. Some uses DAO on Cassandra tables, and that doesn't require any database connections at all (but Thrift connection, for example). Interfaces "hides" all these irrelevance. – Buhake Sindi Nov 14 '11 at 12:21
1

I have only done the implementations of service layer, didn't bother with interfaces (except where I had to). I probably should get around to writing the interfaces, but no problems so far. I am doing unit testing just fine without mocking the service layer.

Also, I don't have a DAO layer, as I am using hibernate and it seemed overkill. A lot of my reasoning is based on this blog, eloquently written by Bozho.

I think it is quite debatable (whether to have DAO and hibernate), however I am quite happy with my decision, I pass in thick domain objects and then just make a call to the hibernate session. Each method on the dao layer would literally only be one line (session.persist(mObject), or similar).

One argument I heard against it was a dao layer would make it easier to change/remove orm at a later date. I am not sure if the time spent coding the dao layer in the first place added to the time coding the change, would be less than coding the change without dao layer on its own. I have never had to change ORM technology any where I worked so its a small risk.

Community
  • 1
  • 1
NimChimpsky
  • 46,453
  • 60
  • 198
  • 311
  • so you use the hibernate methods inside service layer directly ? – fresh_dev Nov 14 '11 at 12:15
  • 1
    I would do the same. Start with the implementation and introduce interface when more than one implementation would arise. However, if the service should be visible to many clients at the beginning - then interface introduction seems to be reasonable. – Piotr Nowicki Nov 14 '11 at 12:37
1

From my point of view when you say Service you should have interfaces and if you can't provide or will not provide that, then you don't have the contract between the service and the consumer and it's not a service anymore, you can call it anything else

Mohamed.Radwan -MVP
  • 2,724
  • 2
  • 16
  • 24
0

The interface+implementation is used in order to have loose coupling. You have the flexibility of changing or switching implementations easily without major changes in code.

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

If you are using interfaces, you can simply write an implementation specific to JPA and "plug" it in place of Hibernate. The service code remains the same.

Manish
  • 3,913
  • 2
  • 29
  • 45
  • what about if i am using an AbstractDao that contains generic methods for CRUD operations and all the DAOs extends that AbstractDao i guess that would be sufficient than using interface with daos, or i will need to extend the BasicDao and implement the interface both ? – fresh_dev Nov 14 '11 at 12:18
0

Another argument for interface+implementation model is that proxies for interfaces are supported by Java itself while creating proxies for implementations requires using library such as cglib. And this proxies are necessary for transaction support etc.

Danubian Sailor
  • 1
  • 38
  • 145
  • 223
0

Check out my post about "fastcode" an eclipse-spring plugin that generates the service layer off your DAO's. Works like a charm. generate service /dao layer for GWT/Spring/Hibernate/PostgreSQL

Community
  • 1
  • 1
logixplayer
  • 939
  • 2
  • 13
  • 23