MVC3应用程序，在现有架构上

Question

我有一个实体框架驱动的解决方案，在此基础上，我有一个业务层和一个服务层，向我的测试控制台应用程序公开方法。控制台应用程序不知道我的实体框架。我有一个转换类，它接受实体框架数据对象，并将它们转移到共享库项目中的自定义DTO。因此，我的数据库访问层使用共享库，我的其他层也是如此。

现在，我想尝试构建一个MVC3应用程序。那么，在我的解决方案中将其构建为单独的项目是否正确，然后让MVC应用程序的控制器部分引用我当前解决方案的服务层？例如，我的服务层公开了一个名为“GetAllUsers”的方法，该方法返回一个List。然后我获取该List，并形成一个模型（MVC的M部分），并将其传递给视图。这看起来好吗？

Answer 1

我不是一个大专家，但我认为没关系，而且是正确的。根据我创建MVC应用程序的经验，将MVC应用程序本身与整个解决方案的其他部分（如数据库，数据库模型或数据库模型类，数据库存储库，业务模型等）分开是正确的。此外，如果需要，您可以根据服务层在MVC应用程序项目中直接创建ViewModel类。即创建一个更多的抽象级别，并仅使用控制器将结果发送到视图而不是处理列表。

Answer 2

要回显Dima - 您可以考虑再次将DTO映射到专门针对视图定制的自定义ViewModel类（否则，您可能会发现自己必须使用ViewBag等将其他数据填充到View中）

还要确认MVC的“M”实际上是系统的整个后端（DAL，BLL，服务层，DTO，实体等）。我们通常删除asp.net MVC项目中的Model文件夹，因为其他层位于单独的程序集中并被引用/注入。我假设您的MVC前端是您系统的“主要”UI（即同一团队正在开发MVC前端和后端）。

服务层就是一个有争议的问题 - 至少有以下两个选项。

1. 您可以认为服务层仅用于“外部”系统使用者，并允许您的控制器直接与您的BLL交互，甚至（CQRS样式）直接与DAL / Repository进行查询（即服务层=暴露的集成）接口门面）。 （但是你自己的前端Ajax调用等应该调用MVC控制器方法，而不是服务层IMO）
2. 采用更传统的严格分层方法，并将服务层视为业务层的网关（即，您的MVC前端根本不是服务的特殊使用者，必须通过服务层）。

使用选项1，您可能需要复制Controller中的服务问题（安全性，事务边界，日志记录等）。通常，控制器无论如何都需要这些担忧。

使用选项2，例如如果您使用的是WCF，则应尽可能避免额外的网络（和序列化/反序列化）开销。因此，如果您发现可以将MVC前端和服务层部署到同一物理服务器，您可以配置一个IoC（或classfactory）将WCF服务合同实例直接注入您的控制器（即您仍然通过定义的WCF合同通过服务层，但没有开销）。

同样使用选项2，如果您有其他系统正在使用您的服务（除了您自己的前端），建议您正式化您的界面，例如：通过外部消费者的额外外观/映射。否则，每次向自己的前端添加新属性或方法到WCF服务时，都会破坏合同外部使用者。 WCF MessageContract对外部系统接口很有用，因为您可以更好地控制消息格式。