Web 应用程序和 Web 服务层的依赖注入过多
本文关键字：Web 注入 依赖 应用程序 服务 | 更新日期: 2023-09-27 18:31:25
我们有一个网站应用程序和一个Web服务层。根据我们的要求，网站必须使用网络服务获取数据。这两层都是由我构建的。我很好奇我的 DI 布局是否合理。
公共实体项目 - 由网站和 Web 服务层共享
ASP.NET MVC网站-- MVC 服务层 - 注入具体类以包含网站/页面的业务规则-- -- 数据存储库 - 由 MVC 服务层注入。在这种情况下，当前有用于Web服务调用的各种包装器，但情况可能会发生变化
网络服务-- 服务/业务层 - 注入类来处理服务的业务逻辑-- -- 数据存储库 - 上面业务层使用的注入数据类。可以是 ADO 或 EF。
因此，任何调用都可以是多达 4 层的注入。我看到了这样做的好处，因为每个部分都可以隔离和测试。在某些情况下，业务层可以"传递"到数据层（例如，GetClientByID（int id）几乎没有逻辑），但是在规则发生变化的情况下存在。我觉得数据层的注入从 Web 服务中抽象出任何自动生成的实体。幸运的是，就我而言，它目前共享一个共同的项目，但谁知道这是否保持这种状态。
这是不是太多了？谢谢。
你的问题非常主观，但无论如何我都会尝试回答。
您将应用程序分解为逻辑层，每个逻辑层都可以进行单元测试。这通常是一件好事。不同的抽象点或接口意味着，如果需要，您可以轻松交换逻辑，从而使应用程序更具可扩展性和可维护性。
是不是太多了？
这实际上取决于几个因素——截止日期、预算、项目的预期寿命等。您需要构建的层越多，前期投资就越大，以后需要维护的层就越多。但是抽象使得交换业务逻辑变得更加容易 - 这通常值得前期成本。
但是，对于您的 DI 容器来说，它是否太多了？不。请记住，DI 的目的是简化应用程序的复杂性。您拥有的层和服务越多，使用 DI 就越有意义。DI 使您的应用程序层和服务不直接相互依赖，因此可以毫不费力地替换它们。此外，如果使用组合根模式并使用构造函数注入，则 DI 通常具有非常低的开销，因此性能几乎从不是一个因素。