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

Question

为了理解MVC 2并试图让我的公司将它作为未来开发的可行平台，我近来一直在进行大量的阅读。在过去的几年里，我一直非常专注于ASP.NET，我有一些工作要做。

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

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

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

我已经看过演示，帖子等，但我似乎无法找到任何简单的解释模式，并给我引人注目的证据使用它。

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

Answer 1

在MVC模式中，您有责任在三个玩家之间分开：模型，视图和控制器。

该模型负责执行业务内容，该视图显示业务结果（为用户提供业务输入），而控制器的行为类似于模型和视图之间的粘合，将内部彼此的工作。

该模型通常由数据库进行备份，因此您有一些DAO可以访问该数据库。你的业务做了一些......嗯......业务和存储或从数据库中检索数据。

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

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

如果你不使用它会怎么样？

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

如果控制器是以网络为中心的，它将不得不接收它的输入并提供响应作为HTTP请求，响应。但是如果我想从一个与RPC或其他东西进行通信的Windows应用程序调用我的应用程序（并访问它提供的业务）呢？然后怎样呢？

那么，你将不得不重写控制器，并使逻辑客户端不可知论者。但有了服务层，你已经有了。你不需要重写东西。

服务层提供与未绑定到特定控制器实现的DTO的通信。如果控制器（不管是哪种类型的控制器）提供适当的数据（不管源），你的服务层将为调用者提供服务，并隐藏调用者从事涉及的业务逻辑的所有责任。

Answer 2

我不得不说我同意上述dpb，包装即服务层可重用，可嘲弄，我目前正在将这一层包含在我的应用程序中......这里有一些问题/要求我正在思考（很快：p）可能会对你自己有所帮助...
1.需要许多不同用户访问的多个门户（例如博客门户，客户门户，内部门户）。它们都必须是单独的ASP.NET MVC应用程序（一个重要的要求）
2.在应用程序本身中，对数据库的一些调用将类似，数据从存储库层处理的方法和方式。毫无疑问，来自每个模块/门户的一些控制器会对同一个调用进行完全或重载的版本，因此可能需要一个服务层（代码到接口），然后我将在一个单独的类项目中进行编译。
3.如果我为服务层创建单独的类项目，则可能需要对数据层执行相同的操作，或将其与服务层结合使用，并使模型远离Web项目本身。至少在我的项目增长的时候，我可以抛出数据访问层（即LinqToSql - > NHibernate），或者团队成员不需要处理任何其他项目中的任何代码。缺点可能是他们可能吹的一切了大声笑...