Service and DAO vs MVC

Question

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.

Answer 1

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

Answer 2

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.