1

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

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

4

2 回答 2

2

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

于 2012-08-20T02:09:09.300 回答
1

为了呼应 Dima - 您可以考虑再次将您的 DTO 映射到ViewModel专门为视图定制的自定义类（否则，您可能会发现自己不得不使用ViewBagetc 将其他数据填充到视图中）。

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

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

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

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

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

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

于 2012-08-20T05:35:25.213 回答