MVCS - 模型视图控制器服务
我已经使用 MVC 很长时间了，听说过“服务”层（例如在 Java Web 项目中），我一直想知道这是否是真正的架构模式< /strong> 鉴于我找不到很多有关它的信息。
MVCS 的思想是在控制器和模型之间建立一个服务层，以封装控制器中可能存在的所有业务逻辑。这样，控制器就可以转发和控制执行。您可以在许多控制器（例如网站和 Web 服务）中调用服务，而无需重复代码。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
服务层可以用多种方式解释，但它通常是您拥有核心业务处理逻辑的地方，并且位于 MVC 架构下方、数据访问架构上方。
例如，完整系统的层可能如下所示：
然后服务层将负责：
您在 MVC 中使用的模型可能来自也可能不来自您的服务。您可能想要获取您的服务为您提供的结果，并将它们处理成更适合您的媒体（例如：网页）的模型。
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:
The service layer would then be responsible for:
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).
我自己一直在思考这种模式，但没有在其他地方看到任何对此的引用，并搜索了 Google，并在这里找到了您的问题:)
即使在今天，也没有太多人谈论或发布有关
视图控制器服务模式的内容。
想让你知道其他人也有同样的想法，上图是我的看法。
目前我正在我正在进行的一个项目中使用它。
我将它放在模块中，上图中的每一层都有它自己的独立模块。
服务层是“连接器”“中间人”“服务器端控制器”，因为“客户端”控制器为客户端执行的操作，“服务”为服务器执行的操作。
换句话说，客户端“控制器”仅与“服务”（又称服务器端控制器）“对话”。
控制器--->来自<-----服务层的请求和接收
服务层获取信息或向需要信息的服务器端的各层提供信息。
服务本身不执行任何操作，只是将服务器层与其所需的内容连接起来。
以下是代码示例：
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:
我已经使用 MVCS 模式很多年了，我不知道其他人也这样做过，因为我在网上找不到任何可靠的信息。如果你愿意的话，我开始本能地使用它，它永远不会让我对 Laravel 项目失望。我想说，对于中型项目来说，这是一个非常易于维护的解决方案，尤其是在业务逻辑不断变化的敏捷环境中工作时。实现关注点分离非常方便。
说到这里，我发现服务层对于小型项目或原型之类的东西来说是不必要的。我在制作原型时犯了一个错误，那就是使项目过于复杂化，这最终意味着需要更长的时间才能实现你的想法。如果您真的想在中期维护项目，那么 MVCS 在我看来是一个完美的解决方案。
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.