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 回答