Why do we need to write same methods in Service Interface, when we just want a replica of DAO Interface.

interface DAOI

interface ServiceI extends DAOI


instead of below

interface ServiceI 
  • 4
    Who says you do?
    – Paul
    Oct 6, 2017 at 11:27
  • @paul do you mean, I can go ahead and follow this approach Oct 6, 2017 at 11:35
  • 3
    If your service interface only replicate the DAO interface, you didn't design a service. Just calling a class SomewhatService doesn't suffice. If you only have a simple CRUD use cases a service (in design and naming) is possibly dispensable.
    – blafasel
    Oct 6, 2017 at 11:45
  • @blafasel Yeah, I think the same. I am implementing Service Layer just for name sake. Oct 6, 2017 at 11:50
  • 2
    Understand it isn't the problem that is making you do this. You're deciding to do this. Doing this works but it puts the database at the center of your application instead of the business rules. It's up to you which you're going to do: rigidly follow the whims of the DB or follow the problems business rules. But I will say if you're just going to make a CRUD app then using a general purpose language is a waste. If you're going to toss out flexibility for convenience look into 4th generation languages. This is what they're good at. Oct 6, 2017 at 14:17

1 Answer 1


If Service Layer is doing nothing, just calling methods in DAO. Can my Service Interface just extend DAO Interfaces?


You don't have a service layer for the sake of having a service layer. It's a layer that further hides your data source and how that's implemented and also adds coordination logic for the DAOs (Say you have an user action that involves access to multiple DAOs. Who would coordinate that?). In most cases your service layer also contains your application business logic.

Might want to read on the Service Layer before anything else. See the following questions just to get you started:



A service layer is considered an anti-pattern by OOP purists (i.e. an anemic domain model) but it is useful in large enterprise applications because it offers an easier model to work with and also allows it to be used as a transaction boundary. Again, you can find advantages and disadvantages of a service layer online.

Getting back to your question. If your service layer is just calling a DAO, then that's what it's doing. You need to preserve the abstraction and not have services build in a way in some place, and services built in another way somewhere else. Be consistent. Have the simple services just delegate to the DAOs, not implementing them.

Not sure from where your question arose, but just to cover this point also, if you are learning to build an application using service layers and DAOs, be aware that most books, tutorials, etc, don't quite go into explanations or complex details, so most service examples just delegate to DAOs, letting people scratching their heads and thinking "Well this is dumb! Why have an extra layer that does nothing? Just call the DAOs. Done. Much better". Well, NO.

So if you have a service layer, keep it clean and at a higher level of abstraction. Don't pollute it with your DAOs. Inject the DAOs instead and delegate to them.

  • 1
    Holy... DAOs 26 times.
    – Konrad
    May 14, 2018 at 7:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.