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