目前，我了解存储库模式，模型，控制器，数据注释等。但是有一件事让我完全不了解开始工作的参考应用程序。
第一个是服务层模式。我在Stack Overflow上看过很多博客文章和问题，但是我仍然不能完全理解这种模式的目的。我在MVCentral上观看了高尔夫跟踪应用程序的整个视频系列，并且还查看了他发布的演示代码，并且看起来像我的服务层只是一个完全没有任何工作的存储库模式的另一个包装。
我也读了这篇文章：http://www.asp.net/Learn/mvc/tutorial-38-cs.aspx，似乎有些回答我的问题，但是，如果你使用数据注释来执行验证，这似乎是不必要的。
我已经寻找示威，帖子等等，但是我似乎找不到任何简单解释模式的东西，并给出了令人信服的证据来使用它。
有人可以给我一个二年级(好的，也许是5年级)的理由来使用这种模式，如果没有，我会失去什么，如果我做的话我会得到什么？
解决方法
该模型负责做业务，View提供了业务的结果(也为用户提供了业务的输入)，而控制器就像模型和视图之间的粘合一样，将每个对象的内部工作另一个。
该模型通常由数据库备份，因此您可以访问一些DAO。您的业务有一些…好的…在数据库中进行业务和存储或检索数据。
但谁协调DAO？控制器？没有！模型应该。
进入服务层。服务层将为控制器提供高服务，并在幕后管理其他(较低级别)的玩家(DAO，其他服务等)。它包含您的应用程序的业务逻辑。
如果不使用它会怎么样？
你必须将业务逻辑放在某个地方，受害者通常是控制器。
如果控制器是以Web为中心的，则必须接收其输入并提供响应作为HTTP请求，响应。但是，如果我想从与RPC或其他一些事情进行通信的Windows应用程序中调用我的应用程序(并访问其提供的业务)呢？然后怎样呢？
那么你将不得不重写控制器，使逻辑客户端不可知。但是服务层已经有了。 Yyou不需要重写东西。
服务层提供与DTOS的通信，这些DTO与特定的控制器实现无关。如果控制器(无论什么类型的控制器)提供适当的数据(没有源)，您的服务层将为其提供服务，并将呼叫者隐藏所涉及的业务逻辑的所有责任。
