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