服务层和 ASP.NET MVC 2 的目的

Question

为了努力理解 MVC 2 并尝试让我的公司采用它作为未来开发的可行平台，我最近进行了大量阅读。过去几年我一直在专门使用 ASP.NET，所以我还有一些工作要做。

目前，我了解存储库模式、模型、控制器、数据注释等。但有一件事使我无法完全理解并开始参考应用程序的工作。

第一个是服务层模式。我在 Stack Overflow 上阅读了很多博客文章和问题，但我仍然不完全理解这种模式的目的。我在 MVCCentral 观看了有关 Golf Tracker 应用程序的整个视频系列，还查看了他发布的演示代码，在我看来，服务层只是存储库模式的另一个包装器，根本不执行任何工作。

我还读过这篇文章： http://www.asp.net/Learn/mvc/tutorial-38-cs.aspx 它似乎在某种程度上回答了我的问题，但是，如果您使用数据注释来执行验证，这似乎是不必要的。

我寻找过演示、帖子等。但我似乎找不到任何可以简单解释该模式并为我提供使用它的令人信服的证据的东西。

有人可以向我提供使用这种模式的二年级（好吧，也许是五年级）的理由，如果我不这样做我会失去什么，如果我这样做我会得到什么？

Answer 1

在 MVC 模式中，三个参与者的职责是分开的：模型、视图和控制器。

模型负责处理业务，视图呈现业务结果（还提供用户对业务的输入），而控制器则充当模型和视图之间的粘合剂，将每个视图的内部工作与视图分开。另一个。

模型通常由数据库备份，因此您可以有一些 DAO 访问该模型。您的企业确实做了一些……嗯……业务并在数据库中存储或检索数据。

但谁来协调 DAO？控制器？不！模型应该。

进入服务层。服务层将为控制器提供高级服务，并在幕后管理其他（较低级别）参与者（DAO、其他服务等）。它包含您的应用程序的业务逻辑。

如果不使用它会发生什么？

您必须将业务逻辑放在某个地方，而受害者通常是控制器。

如果控制器以 Web 为中心，它将必须接收其输入并提供 HTTP 请求、响应等响应。但是，如果我想从与 RPC 或其他东西通信的 Windows 应用程序调用我的应用程序（并访问它提供的业务）该怎么办？然后怎样呢？

好吧，您将必须重写控制器并使逻辑客户端变得不可知。但有了服务层，你就已经拥有了。你不需要重写东西。

服务层提供与不依赖于特定控制器实现的 DTO 的通信。如果控制器（无论什么类型的控制器）提供适当的数据（无论来源），您的服务层将尽其所能，为调用者提供服务，并隐藏调用者所涉及的业务逻辑的所有责任。

Answer 2

我不得不说我同意DPB的同意以上，包装器IE服务层是可重复使用的，可模拟的，我目前正在将此层包含在我的应用中...这是我正在思考的一些问题/要求（很快：P）可能会帮助您...
1.多个门户（例如Bloggers Portal，客户端门户网站，内部门户）将需要许多不同的用户访问。它们都必须是单独的ASP.NET MVC应用程序（重要的要求）
2.在应用程序本身中，对数据库的一些调用将是相似的，方法和数据从存储库层处理的方式。毫无疑问，每个模块/门户的某些控制器将精确地制作或同一调用的超载版本，因此可能需要使用服务层（与接口的代码），然后我将在单独的类项目中编译。
3.如果我为我的服务层创建一个单独的类项目，我可能需要为数据层做相同的操作或将其与服务层结合，并使模型远离Web项目本身。至少随着项目的发展，我可以抛出数据访问层（即linqtosql-> nhibernate），或者团队成员可以无需处理任何其他项目中的任何代码即可。不利的一面是他们可以炸毁一切哈哈...