c# - MVC web项目的架构/不同类型模型的使用

Question

我正在构建一个目前有 3 个程序集的项目:

• 用户界面
• 核心(服务和模型、实用程序)
• 存储库 (Linq2SQL)

依赖是

• 用户界面 -> 核心
• 核心 -> 存储库。

我希望服务和模型在它们自己的程序集中，并以围绕模型构建的东西结束，即:

• UI ->模型、服务
• 服务 -> 模型、存储库
• 存储库 -> 模型
• 模特

我正在构建的系统基本上是一个网站 CMS，因此我将有一个网页模型 (PageModel)，其中包含子网页的集合。 PageModel 可以调用服务 (PageService) 中的方法来填充其子页面，但在新设计中这不会发生，因为模型程序集必然对服务程序集一无所知。

我已经考虑了 Onion Architecture 中的一些想法(即依赖注入(inject))来解决这个问题，但似乎可以使用更优雅/明显的解决方案。

需要再引入一层Model吗？查看模型？我认为我所说的模型是领域模型……我很可能是错的!服务将成为领域服务？

所以我的解决方案是:

• UI -> 服务、 View 模型、模型
• ViewModels -> 服务、模型
• 服务 -> 存储库、模型
• 存储库 -> 模型
• 模特

在这个例子中，我想象我的 PageViewModel 会扩展 PageModel 并使用 PageService 来获取它的子页面。

任何建议表示赞赏。还有关于这些模型层通常被称为什么的指针吗？我在这里谈论的是 DTO 模型而不是域模型吗？领域模型而不是 View 模型？看起来我提议使用 View 模型的目的并不是 View 模型的真正工作。

谢谢

编辑:

我最初没有提到的一点是，我的领域模型并不是像您在大多数教程中看到的那样对单个数据库实体的基本翻译。域模型可以包含来自多个相关数据库表的数据字段。

那么是否值得拥有一组纯粹用于封装域中数据的模型——没有任何方法/属性来获取相关对象或将对象保存回数据库等？ - 数据传输对象。

从几个潦草的图表来看，这意味着在域层中有一组映射器(这似乎是错误的..)将 DTO 模型转换为域模型并返回。该项目将围绕 DTO 模型而不是域模型构建，但考虑到 DTO 封装的内容，我认为这不是问题。

对于任何感兴趣的人，建议的依赖结构如下:

• UI -> 服务、领域模型
• 服务 -> 存储库、领域模型、DTO 模型
• 领域模型 -> 存储库、DTO 模型
• 映射器 -> 域模型、DTO 模型
• 存储库 -> DTO 模型
• DTO 模型(无依赖项)

有点乱!这一切都只是因为我希望我的 PageModel 能够获取它自己的子 PageModels..看起来尝试依赖注入(inject)可能不是一个糟糕的计划。

感谢回复的人。你给了我很多思考的机会。

Answer 1

您可以使用洋葱架构很好地完成此任务。我会举个例子:UI、域、数据访问、服务

用户界面服务数据访问域(也包含 View 模型)

UI可以访问任何一个。服务，只有数据访问和域。数据访问 - 仅限域。

我的存储库接口(interface)在域项目中，它们在数据访问项目中实现。我还在域项目中保留其他接口(interface)(IContext、IUnitOfWork 等)，这样我就有了一个中心位置，不会在项目之间分散太多接口(interface)。

如果您认为合适，DTO 将仅用于层间传输。我没有理由不能从数据层向上传递域模型，有些人选择只在这里使用 DTO。我将在 UI 层(前 MVC Controller )中映射到 ViewModel，因为我可以利用 AoP 为我做这件事([AutoMap()] 属性)

请记住，您的模型根本不应包含任何持久性逻辑。