我们有一个网站应用程序和一个Web服务层。网站必须根据我们的要求使用Web服务获取数据。这两个层都是由我构建的。我很好奇我的DI布局是否合理。
公共实体项目 - 由网站和Web服务层共享
ASP.NET MVC网站 - MVC服务层 - 注入具体类以包含网站/页面的业务规则 - - 数据存储库 - 由MVC服务层注入。在这种情况下，当前Web服务调用的各种包装器，但事情可能会改变
Web服务 - 服务/业务层 - 注入的类来处理服务的业务逻辑 - - 数据存储库 - 上面的业务层使用的注入数据类。可以是ADO或EF。
因此，任何呼叫最多可以进行4层注射。我看到了这方面的好处，因为每个部分都可以被隔离和测试。在某些情况下，业务层只能通过＆＃34;到数据层（例如，GetClientByID（int id）几乎没有逻辑），但是在规则改变的情况下。我觉得数据层的注入会从Web服务中抽象出任何自动生成的实体。幸运的是，在我的情况下，它目前共享一个共同的项目，但谁知道这是否保持这种状态。
这太多了吗？感谢。
答案 0 :(得分：2)
你的问题非常主观，但无论如何我都会尽力回答。
您正在将应用程序分解为逻辑层，每个层都可以进行单元测试。这通常是件好事。不同的抽象点或接口意味着您可以在需要的时候轻松交换逻辑，这使得应用程序更具可扩展性和可维护性。
太多了吗？
这实际上取决于几个因素 - 截止日期，预算，项目的预期寿命等。您需要构建的层数越多，前期投资越大，以后需要维护的层数越多。但是抽象使得交换业务逻辑变得更容易 - 这通常使得前期成本变得有价值。
但是你的DI容器处理得太多了吗？不。请记住，DI的目的是简化应用程序的复杂性。您拥有的层和服务越多，使用DI就越有意义。 DI使得您的应用程序层和服务不会直接相互依赖，因此可以轻松更换它们。此外，如果你使用Composition Root pattern并使用构造函数注入，DI通常具有非常低的开销，因此性能几乎不是一个因素。