MVC应用程序架构的数据流

时间:2015-06-11 00:50:49

标签: c# asp.net-mvc architecture

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

enter image description here

几个问题。

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

2 个答案:

答案 0 :(得分:1)

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

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

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

答案 1 :(得分:1)

似乎已经相当不错了。

通常我有以下分层:

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

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

表示层的控制器很薄,只使用服务层(和基础结构层)。

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