C# MVC应用体系结构的数据流

尝试验证我正在清理和优化的MVC应用程序中的数据流方法（经过一点重构后），目前的情况如下图所示（箭头所示的数据流）。编写某些部分是为了跨层访问存储库服务。（就像HTML助手直接访问存储库服务以查找数据）

几个问题

这是一种典型的设计吗？是否存在缺陷

为琐事跳过图层是否可以接受

数据流在架构上是否合理

这似乎是一种常见的设计。不幸的是，我没有足够的经验来指出设计中的缺陷，因为我目前参与的项目是我第一次体验这种架构

如果您说存储库服务是在多个层中访问的，那么您不缺少几个箭头吗？理想情况下，您不希望从控制器（或Razor助手）访问存储库，因为这会使您的代码更紧密地耦合在一起，并且会弄乱您原本良好的关注点分离。然而，这并不是说在多个模块中有一些有限的存储库访问是可怕的。最佳实践是将这些存储库调用移动到您的业务逻辑中，并将其传递给控制器

我目前参与的ASP.NET项目使用了非常类似的体系结构，我们在这方面取得了成功

---

看起来已经很好了

通常我有以下分层：

• 表示层：包含带有模型、控制器、视图和视图模型的MVC网站
• 服务层：包含对表示层中的所有内容公开的服务（以WCF服务或web API的形式，甚至只是一个类库）
• 应用程序层：包含应用程序逻辑，在我的例子中，这些是使用底层域模型和基础结构服务的命令和查询处理程序
• 域层：域实体和服务，与其他层没有依赖关系，并且包含域逻辑
• 基础架构层：包含基础架构关注点，如数据访问、日志记录等

为了最小化依赖性，我针对接口编程；其中的具体实现由IoC容器注入。这意味着每个组件都是非常可测试的

表示层的控制器很薄，并且只使用服务层（和基础结构层）

---

这是一种非常灵活的方法，但非常简单，适用于大多数类型的应用程序。另外，如果您使用实体框架，您可能需要考虑是否确实需要存储库和工作单元。

嘿，谢谢，但我省略了箭头，因为这些情况都是例外，我想知道的是上面描述的数据流是否正确。编辑以试图为您的问题提供更好的答案只是一个关于#2 Tyler的问题。如果您无法从控制器访问存储库，那么如何在视图中显示存储库中的数据？它必须进入控制器才能在某个时候被视图转换，不是吗？业务逻辑层中有管理者将此信息传递给控制器。因此控制器可以访问存储库，但不能直接访问。仅供参考，@tylergona引用的管理器称为域服务。通常，在控制器和域之间有一个服务层，在域服务/对象和视图模型之间转换，这样控制器就不需要直接了解域了。@BJSafdie谢谢，听起来很合理。