为了理解 MVC 2 并试图让我的公司采用它作为未来发展的可行平台，我最近做了很多阅读。在过去的几年里，我完全专注于 ASP.NET，我有一些事情要做。
目前，我了解存储库模式、模型、控制器、数据注释等。但有一件事让我无法完全理解，无法开始研究参考应用程序。
第一个是服务层模式。我在 Stack Overflow 上阅读了很多博客文章和问题，但我仍然不完全理解这种模式的目的。我在 MVCCentral 上观看了 Golf Tracker 应用程序的整个视频系列，还查看了他发布的演示代码，在我看来，服务层只是存储库模式的另一个包装器，根本不执行任何工作。
我还阅读了这篇文章：http ://www.asp.net/Learn/mvc/tutorial-38-cs.aspx它似乎在某种程度上回答了我的问题，但是，如果您使用数据注释来执行验证，这似乎没有必要。
我一直在寻找演示、帖子等，但我似乎找不到任何可以简单解释该模式并为我提供使用它的令人信服的证据的东西。
有人可以给我一个二年级（好吧，也许是五年级）使用这种模式的理由，如果我不这样做我会失去什么，如果我这样做我会得到什么？
在 MVC 模式中，您的职责分为 3 个参与者：模型、视图和控制器。
Model 负责做业务，View 呈现业务的结果（也提供来自用户的业务输入），而 Controller 就像是 Model 和 View 之间的粘合剂，将每个内部工作与另一个。
该模型通常由数据库备份，因此您有一些 DAO 访问它。您的企业做了一些......好吧......业务并在数据库中/从数据库中存储或检索数据。
但是谁来协调 DAO？控制器？不！模型应该。
进入服务层。服务层将为控制器提供高级服务，并将在幕后管理其他（较低级别）参与者（DAO、其他服务等）。它包含您的应用程序的业务逻辑。
如果你不使用它会发生什么？
您必须将业务逻辑放在某个地方，而受害者通常是控制器。
如果控制器是以 Web 为中心的，它将必须接收其输入并以 HTTP 请求、响应的形式提供响应。但是，如果我想从与 RPC 或其他东西通信的 Windows 应用程序调用我的应用程序（并访问它提供的业务）怎么办？然后怎样呢？
好吧，您将不得不重写控制器并使逻辑客户端不可知。但是使用服务层，您已经拥有了它。你不需要重写东西。
服务层提供与 DTO 的通信，这些 DTO 不依赖于特定的控制器实现。如果控制器（无论哪种类型的控制器）提供了适当的数据（无论来源），您的服务层将尽其所能为调用者提供服务，并将调用者从所涉及的业务逻辑的所有责任中隐藏起来。
我不得不说我同意上面的dpb，包装即服务层是可重用的，可模拟的，我目前正在将这个层包含在我的应用程序中......这是我正在思考的一些问题/要求（很快 :p ）这可能对你自己没有帮助...
1. 多个门户（例如 Bloggers 门户、客户门户、内部门户）需要被许多不同的用户访问。它们都必须是单独的 ASP.NET MVC 应用程序（一个重要要求）
2. 在应用程序本身内，对数据库的一些调用将是相似的，方法和从存储库层处理数据的方式。毫无疑问，来自每个模块/门户的一些控制器将完全或重载同一调用的版本，因此可能需要一个服务层（代码到接口），然后我将在一个单独的类项目中编译它。
3.如果我为我的服务层创建一个单独的类项目，我可能需要为数据层做同样的事情，或者将它与服务层结合起来，并使模型远离 Web 项目本身。至少这样，随着我的项目的增长，我可以抛弃数据访问层（即 LinqToSql -> NHibernate），或者团队成员可以不用处理任何其他项目中的任何代码。不利的一面可能是他们可以炸毁一切，哈哈……