MVC应用程序架构的数据流

Question

试图在MVC应用程序中验证数据流的方法，我正在清理和简化（在一些重构之后）当前的事情如下图所示（数据流由箭头指示）。 并编写了一些部分来访问跳过图层的存储库服务。 （就像直接访问存储库服务以查找数据的HTML帮助程序一样）

几个问题。

1. 这是一个典型的设计，有任何陷阱吗？
2. 是否可以跳过琐碎事物的图层？
3. 数据流在架构上是否健全？

Answer 1

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

2. 如果您说存储库服务是在多个层中访问的，那么您是不是错过了几个箭头？ 理想情况下，您不希望从控制器（或Razor帮助程序）访问您的存储库，因为这会使您的代码更紧密地耦合并使您的关注点分散。 但是，这并不是说在多个模块中拥有一些有限的存储库访问权限是很糟糕的。 最佳实践是将这些存储库调用移动到业务逻辑中，然后从那里将其传递给控制器​​。

3. 我目前使用的ASP.NET项目使用的是非常相似的架构，我们正在取得成功。

Answer 2

似乎已经相当不错了。

通常我有以下分层：

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

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

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

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