MVCS - Model View Controller Service

I've been using MVC for a long time and heard about the "Service" layer (for example in Java web project) and I've been wondering if that is a real architectural pattern given I can't find a lot of information about it.

The idea of MVCS is to have a Service layer between the controller and the model, to encapsulate all the business logic that could be in the controller. That way, the controllers are just there to forward and control the execution. And you can call a Service in many controllers (for example, a website and a webservice), without duplicating code.

Solution 1:

The service layer can be interpreted a lot of ways, but it's usually where you have your core business processing logic, and sits below your MVC architecture, but above your data access architecture.

For example, you layer of a complete system may look like this:

1. View Layer: Your MVC framework & code of choice
2. Service Layer: Your Controller will call this layer's objects to get or update Models, or other requests.
3. Data Access Objects: These are abstractions that your service layer will call to get/update the data it needs. This layer will generally either call a Database or some other system (eg: LDAP server, web service, or NoSql-type DB)

The service layer would then be responsible for:

• Retrieving and creating your 'Model' from various data sources (or data access objects).
• Updating values across various repositories/resources.
• Performing application-specific logic and manipulations, etc.

The Model you use in your MVC may or may not come from your services. You may want to take the results your service gives you and manipulate them into a model that's more specific to your medium (eg: a web page).

Solution 2:

I had been thinking of this pattern myself without seeing any reference to this any where else and searched Google and found your Question here :)

Even today there is not much any body talking about or posting about the

View-Controller Service Pattern.

Thought to let you know other are thinking the same and the image above is how I view how it should be.

Currently I am using it in a project I am working on now.

I have it in Modules with each layers in the image above with in it's own self contained Module.

The Services layer is the "connector" "middleman" "server side Controller" in that what the "client" side Controller does for the client, the "Service" does for the server.

In other words the Client side "Controller" only "talks" with the "Service" aka Server Side Controller.

Controller ---> Requests and Receive from the <----- Service Layer

The Service layer fetches or give information to the layers on the server side that needs it.

By itself the Service does not do anything but connect the server layers with what they need.

Here is a code sample:

Solution 3:

I have been using the MVCS pattern for years and I didn't know anyone else did as I couldn't find any solid info on the web. I started using it instinctively if you like and it's never let me down for Laravel projects. I'd say it's a very maintainable solution to mid sized projects, especially when working in an agile environment where business logic changes on the constant. Having that separation of concern is very handy.

Saying this, I found the service layer to be unnecessary for small projects or prototypes and what not. I've made the mistake of over complicating the project when making prototypes and it just ultimately means it takes longer to get your idea out. If you're serious about maintaining the project in the mid term then MVCS is a perfect solution IMO.