据我了解，MVC 通过控制器这一“粘合剂”将类定义（模型）与表示（视图）分开。控制器应该有单一的职责，因此是可测试的。 ViewModel 用于将来自多个实体的数据汇集在一起，并“按摩”来自视图控制器的数据。
似乎业务逻辑并没有真正占有一席之地......所以我认为另一层服务将是合适的。我只是不确定将该层放在哪里，或者如何构建服务 - 它应该是一个包含一堆函数的名为“服务”的类吗？我对 MVC 有点陌生，所以任何阅读材料、示例或一般新手技巧都会很棒。
我在开发 ASP.NET MVC 应用程序时通常使用服务层。它类似于服务层模式 http://martinfowler.com/eaaCatalog/serviceLayer.html马丁·福勒 (Martin Fowler) 在企业应用架构模式。它封装了您的业务逻辑并使控制器变得非常薄。基本上，控制器使用服务层来获取域模型，然后将其转换为视图模型。我也用工作单元设计模式 http://msdn.microsoft.com/en-us/magazine/dd882510.aspx处理交易和存储库设计模式 http://msdn.microsoft.com/en-us/library/ff649690.aspx封装数据访问层，以便更轻松地进行单元测试并能够轻松替换 ORM。该图显示了我在 MVC 应用程序中使用的典型层。
在此图中，服务层被标记为“应用程序或域层”，因为我发现当您使用术语“服务层”时，人们会感到困惑。他们倾向于认为这是一项网络服务。它实际上是一个程序集，可供您最喜欢的 Web 服务技术（例如 ASP.NET Web API 或 WCF）以及控制器使用。
至于命名约定，我通常使用描述域的名称，后跟服务。例如，如果我有一个处理用户成员资格的服务层，那么我将有一个名为 MembershipService 的类，该类具有控制器和 Web 服务查询和操作成员资格域所需的所有方法。请注意，同一应用程序中可能有多个域，因此您可以拥有多个服务层。我的观点是，您不必拥有一个负责整个应用程序的单一服务。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
