1

我们有一个网站应用程序和一个 Web 服务层。该网站必须按照我们的要求使用网络服务获取数据。这两层都是由我建造的。我很好奇我的 DI 布局是否合理。

公共实体项目 - 由网站和 Web 服务层共享

ASP.NET MVC 网站——MVC 服务层——注入具体类以包含网站/页面的业务规则————数据存储库——由 MVC 服务层注入。在这种情况下，目前有各种 Web 服务调用的包装器，但情况可能会发生变化

Web 服务——服务/业务层——注入类来处理服务的业务逻辑————数据存储库——注入上面业务层使用的数据类。可以是 ADO 或 EF。

所以，任何调用最多可以进行4层注入。我看到了这样做的好处，因为每个部分都可以被隔离和测试。在某些情况下，业务层可以只是“通过”到数据层（例如，GetClientByID(int id) 几乎没有逻辑），但在规则发生变化时会存在。我觉得数据层的注入从 Web 服务中抽象出任何自动生成的实体。幸运的是，就我目前而言，它共享一个共同的项目，但谁知道这是否会保持这种状态。

这太多了吗？谢谢。

4

1 回答 1

2

您的问题非常主观，但无论如何我都会尝试回答。

您正在将应用程序分解为可以进行单元测试的逻辑层。这通常是一件好事。不同的抽象点或接口意味着您可以在需要时轻松交换逻辑，这使应用程序更具可扩展性和可维护性。

是不是太多了？

这实际上取决于几个因素 - 截止日期、预算、项目的预期寿命等。您需要构建的层数越多，前期投资就越大，以后需要维护的层数也就越多。但是这些抽象使得交换业务逻辑变得更容易——这通常使得它值得付出前期成本。

但是对于您的 DI 容器来说处理太多了吗？不。请记住，DI 的目的是简化应用程序的复杂性。您拥有的层和服务越多，使用 DI 就越有意义。DI 使您的应用程序层和服务不直接相互依赖，因此可以毫不费力地替换它们。此外，如果您使用组合根模式并使用构造函数注入，则 DI 通常具有非常低的开销，因此性能几乎从来不是一个因素。

于 2013-09-13T22:43:25.627 回答