MVCS - Model View Controller Service

model-view-controller architecture architectural-patterns

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.

"I've been wondering if that is a real architectural pattern" ... well, No more or less real than other design patterns :) It's all about picking the abstraction that makes the most sense -- in this case, MVCS seems to be a more useful abstraction than MVC when you're dealing with a variety of up-stream data sources (database models, other web services, etc), and particularly so when you start thinking about exposing YOUR work as a service. This pattern has helped me re-use a lot of code when I had a web app I later exposed as a REST API.

Aashutosh Rathi

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:

View Layer: Your MVC framework & code of choice Service Layer: Your Controller will call this layer's objects to get or update Models, or other requests. 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).

I usually use services for external access. While MVC will contain all my app specific logic, I'll use something like DBService, or FacebookOAuthService for all the external calls to other systems. Or to wrap a third party lib rather than tightly integrating, makes it easier to switch out libs. For me it made a lot of sense thinking about services like this.

To add to this, your Model from the Services layer will be more of a Data Transfer Object, this may or may not translate directly into something that meets the requirments of the view directly

This makes it sound like it's just MVC but with an added facade to keep the controller clean.

Kbdavis07

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.

https://i.stack.imgur.com/jWS06.jpg

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.

https://i.stack.imgur.com/FeLwQ.jpg

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:

https://i.stack.imgur.com/D5Jpw.png

The only concern i have with this style of architecture is assuming the DataModels will have the same "shape" as the requirements for the "View". if they're a 1 to 1 or close to it, where you could jam a couple properties specifically for the view I guess it's okay, but a lot of time the DataModels are designed from a storage perspecitve, and a ViewModel is designed from a Views perspective.

There are "DataModels" and "ViewModels", the graphic shown above was done quickly and poorly done :)

Jonathan Port

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.

MVCS - Model View Controller Service

Follow WeChat

Want to stay one step ahead of the latest teleworks?

相似问题

Platform

Support

Contact US