21

I am literally very new to Design Patterns, and I constantly come across words like Service Layers, DAO Layers & Model-View-Controllers in Programming.

As StackOverflow is extremely awesome platform having many extremely talented audience when it comes to explaining concepts and/or logic.

I expect an elegant answer that explains me the difference between all of these. When do we use them? When do we prefer Service/DAO architecture over MVC pattern? Do we have controllers in Service/DAO architecture? What are the possible combinations in which we can integrate Service/DAO and Model/View/Controller.

This post shall also prove helpful for all others who have the same doubt. Good posts should always be supported. Request moderators to not close this as a duplicate of some other question as no question on SO is able to resolve my query.

Nikhil Vartak
  • 5,002
  • 3
  • 26
  • 32
Adil
  • 817
  • 1
  • 8
  • 27
  • 4
    There aren't competing patterns. They work well together. MVC is an architectural pattern that helps organising your code and your application flow. DAO and Service Patterns are not architectural patterns. DAO pattern offers a logic to structure your persistence mechanism (the glue between your database and the model of your MVC). The Service pattern gives a structure that would help locating methods/functionalities to be used in your application. – Maaaatt Aug 03 '17 at 17:29

2 Answers2

15

Service and DAO vs MVC

You should not compare these directly with each other. Services and DAOs form layers in any n-layered application. MVC application can include Services and DAOs.

Service layer is a generic term that basically acts as an entry point to the application domain and typically includes business logic. For a web application, you could treat the business logic layer as a service layer, or for mobile clients, you could expose a web API and treat is a service layer. In short irrespective of GUI/ Client, you should be able to re-use business logic as-is.

DAOs are just the objects that abstract away the data storage mechanism.

MVC is a design pattern where V and C are "strictly" form the presentation layer, and M can include everything that is beyond presentation (GUI). The model part in MVC has been an opinion based topic for a long time. But here's how I would structure a typical MVC application.

Presentation Layer
  -> Views
  -> ViewModels  
  -> Controllers 

Service Layer
  -> Includes business logic
  -> Uses data access interfaces

Data Access Layer (DAOs)
  -> Contracts (interfaces) for persistent storage
  -> Interface implementations

Entities
  -> POCO/ POJO that represent data
Nikhil Vartak
  • 5,002
  • 3
  • 26
  • 32
  • 2
    This means that model & DAo are same, correct? Bdw whar are ViewModels? – Adil Aug 04 '17 at 04:06
  • 2
    *This means that model & DAo are same* - No they are not. `User` model object may contain `Firstname` and `Lastname` however your view needs to display full name. `Fullname` would then be defined by `UserViewModel` because that's just for `View`'s purpose. – Nikhil Vartak Aug 06 '17 at 19:07
12

MVC goes back to Smalltalk. Model-View-Controller usually means "user interface". The Controller is a server side component (for web apps) that accepts requests from View clients, updates the Model appropriately, and sends results back to any and all View clients that need it.

Service/DAO extends those layers to the server side. You can imagine that a web Controller would own multiple Service instances that update the model to fulfill View requests.

The Services will use Model objects to fulfill View requests and persist the outcomes to a database using the data access layer.

Here's what the architecture looks like: 

View ---> Controller ---> Service ---> Data Access Layer

The Model is present in all layers in one form or another.

You will hear a lot about micro-services these days, especially REST. You might wonder where they fit in here.

That's one way to implement the Service layer.

I think of View and Controller as being tightly bound together. They will be implemented for the communication between the client and the back end. User interfaces change a lot - e.g. desktop/tablet, browser, mobile, etc. - but they can all be using the same back end Services to fulfill tasks.

duffymo
  • 305,152
  • 44
  • 369
  • 561