web应用和web服务层的依赖注入太多了吗？
我们有一个网站应用程序和一个web服务层。该网站必须使用网络服务的数据，根据我们的要求。这两层都是由我构建的。我很好奇我的DI布局是否合理。
公共实体项目-由网站和web服务层共享
MVC网站-- ASP.NET服务层--注入具体的类，以包含由MVC服务层注入的网站/页面的业务规则-数据存储库。在这种情况下，目前有各种用于web服务调用的包装器，但情况可能会发生变化
Web服务--服务/业务层-注入类来处理服务的业务逻辑-数据存储库-上面的业务层使用的注入数据类。可以是ADO或EF。
因此，任何调用最多可以有4层注入。我看到了这样做的好处，因为每个部分都可以被隔离和测试。在某些情况下，业务层可以直接“传递”到数据层(例如，GetClientByID(int )几乎没有逻辑)，但是有没有发生规则变化的情况。我感觉数据层的注入从web服务中抽象出了任何自动生成的实体。幸运的是，目前在我的例子中，它共享一个共同的项目，但谁知道这种情况是否会一直保持下去。
这是不是太过分了？谢谢。
回答 1
Stack Overflow用户
发布于 2013-09-14 06:43:26
你的问题很主观，但我还是会试着回答。
您正在将应用程序划分为多个逻辑层，每个逻辑层都可以进行单元测试。这通常是一件好事。不同的抽象点或接口意味着，如果需要，您可以轻松地交换逻辑，这使得应用程序更具可扩展性和可维护性。
是不是太多了？
这真的取决于几个因素-截止日期，预算，项目的预期寿命等。你需要构建的层越多，前期投资就越大，以后需要维护的层也就越多。但抽象使得交换业务逻辑变得更容易-这通常使前期成本变得物有所值。
但是，对于您的DI容器来说，这是否太多了？不是的。请记住，DI的目的是简化应用程序的复杂性。您拥有的层和服务越多，使用DI就越有意义。DI使得您的应用层和服务不会直接相互依赖，因此可以轻松地替换它们。此外，如果您使用Composition Root pattern并使用构造函数注入，DI通常具有非常低的开销，因此性能几乎不是一个因素。
https://stackoverflow.com/questions/18796111
复制相似问题
腾讯云开发者
