0

I have thought a lot about this question, but couldn't found some clear answer on this:

As I've understood at the last time, business layer should works only with model objects. It shouldn't know anything about how and from we fetched this data. It lets us to use business layer API independently of DAO.

So, is it normal to use DAO methods calls inside Service layer or we should trying to reduce dependencies between them. Thus, I see 2 variants of relationships between layers:

  1. Controller –> Service –> Dao
  2. 1 step: modelObject = Controller –> Dao
    2 step: Controller –> Service (modelObject)

So, which variant is right?

Aliaksei Taliuk
  • 1
  • 1

1 Answers1

0

In old architecture there was 2 tier client and server.Server holding all database information and logic .But,the three tier architecture has brought a clear encapsulation and a clear abstraction between layers.In two tier architecture there was no good encapsulation and abstraction and the degree of maintainability, extend ability was a problem because of not having clear encapsulation and abstraction between layers.Client layer does not call directly the service .In stead it uses proxy to call service.For client it acts as a local computer program to call a service.So,client via proxy call service in server which is in middle tier.In middle tier you can assume there can be controller,service,serviceImpl,model without any database related stuff.There is hard and fast rule what can be in middle tier .Just point is it should not mess up with DB stuff.In third tier there is database .Assume dao as a container for the return of db related result.Client should pass call via service and dao should pass result to client via service.

abishkar bhattarai
  • 7,371
  • 8
  • 49
  • 66
  • Thank you for your response. I know that DAO layer (DB staff) should be isolated from other system layers. My question was about what variant of application layers relationships is more appropriate. – Aliaksei Taliuk Dec 10 '12 at 14:05