MVCS - 模型 - 视图 - 控制器服务

我一直在使用MVC很长一段时间，听到了“服务”层（例如Java的web项目），我一直在想，如果这是一个真正的建筑模式鉴于我无法找到关于它的很多信息。MVCS - 模型 - 视图 - 控制器服务

MVCS的想法是在控制器和模型之间有一个服务层，以封装可能在控制器中的所有业务逻辑。这样，控制器就在那里转发并控制执行。你可以在许多控制器（例如，一个网站和一个webservice）中调用一个服务，而不需要复制代码。

2011-04-18 Matthieu Napoli

“我一直在想，如果这是一个真正的建筑模式” ......好，并不比其他设计模式或多或少真实:)这是所有关于选择最有意义的抽象 - 在这种情况下，当您处理各种上游数据源（数据库模型，其他Web服务等）时，MVCS似乎比MVC更有用的抽象，特别是当你开始考虑将你的工作作为一项服务公开时。当我有一个后来公开为REST API的Web应用程序时，该模式帮助我重新使用了大量代码。 – Joe 2012-05-29 17:01:51

服务层可以有许多方法，但它通常是拥有核心业务处理逻辑的位置，并且位于您的MVC体系结构之下，但位于数据访问体系结构的上方。

比如你一个完整的系统层可能看起来像这样：

视图层：你的MVC框架的选择&代码
服务层：您的控制器将调用这一层的对象，以获取或更新模型或其他请求。
数据访问对象：这些是您的服务层调用的获取/更新所需数据的抽象。该层一般会或者调用数据库或者其他系统（例如：LDAP服务器，Web服务，或的NoSql型DB）

服务层将被负责：

Retreiving和从各种数据源（或数据访问对象）创建您的'模型'。
更新各个存储库/资源的值。
执行应用程序特定的逻辑和操作等

模型在你的MVC使用可能会或可能不会与您服务。您可能希望将服务提供给您的结果，并将它们操作为更适合于您的媒介的模型（例如：网页）。

来源

2011-06-02 14:37:17 Clinton

我通常使用外部访问服务。虽然MVC将包含我所有的应用程序特定逻辑，但我会使用DBService或FacebookOAuthService之类的方法来处理其他系统的所有外部调用。或者封装第三方库而不是紧密集成，可以更容易地切换库。对我来说，这对于像这样的服务有很大的意义。 – Lex 2014-06-05 00:07:18

为了补充说明，您的来自服务层的模型将更多地是数据传输对象，这可能会或可能不会直接转化为满足视图需求的东西。 – hanzolo 2017-07-20 16:53:51

没有看到这个任何别的地方，搜查谷歌和发现任何参考我一直在思考这个模式我的你的问题在这里:)

即使在今天，没有太多的任何机构谈论或公布有关

视图 - 控制器服务模式。

以为让你知道其他的都在思考同一个和上面的图片是我认为它应该如何。

目前我正在使用它在我现在正在处理的项目中。

我在模块中使用上图中的每个图层以及它自己的自包含模块。

该服务层是“连接器”，“中间人”，“服务器侧控制器”，该“客户端”侧控制器做什么为客户端，“服务”做为服务器。

换言之，客户端“控制器”只与“服务”即服务器端控制器“通话”。

控制器--->请求和接收从所述< -----服务层

服务层获取或提供信息，以在需要它的服务器侧的层。

服务本身并没有做任何事情，只是连接服务器层和他们需要的东西。

下面是一个代码示例：

来源

2016-11-25 17:20:06 Kbdavis07

我对这种体系结构的唯一担忧是假设DataModel将具有与“View”的要求相同的“形状”。如果它们是1对1或靠近它，那么你可以在视图中专门为视图设置一些属性，但我认为这很好，但是很多时候DataModel是从存储角度设计的，并且ViewModel是根据观点角度。 – hanzolo 2017-07-20 16:52:32

有“DataModels”和“ViewModels”，上面显示的图形很快完成，做得很差:) – Kbdavis07 2017-07-31 21:07:13

MVCS - 模型 - 视图 - 控制器服务

回答

相关问题