问web应用和web服务层的依赖注入太多了吗？
EN

Stack Overflow用户

提问于 2013-09-13 22:19:58

回答 1查看 456关注 0票数 1

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

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

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

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

因此，任何调用最多可以有4层注入。我看到了这样做的好处，因为每个部分都可以被隔离和测试。在某些情况下，业务层可以直接“传递”到数据层(例如，GetClientByID(int )几乎没有逻辑)，但是有没有发生规则变化的情况。我感觉数据层的注入从web服务中抽象出了任何自动生成的实体。幸运的是，目前在我的例子中，它共享一个共同的项目，但谁知道这种情况是否会一直保持下去。

这是不是太过分了？谢谢。

asp.net

.net

asp.net-mvc

dependency-injection

回答 1

Stack Overflow用户

发布于 2013-09-13 22:43:26

你的问题很主观，但我还是会试着回答。

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

是不是太多了？

这真的取决于几个因素-截止日期，预算，项目的预期寿命等。你需要构建的层越多，前期投资就越大，以后需要维护的层也就越多。但抽象使得交换业务逻辑变得更容易-这通常使前期成本变得物有所值。

但是，对于您的DI容器来说，这是否太多了？不是的。请记住，DI的目的是简化应用程序的复杂性。您拥有的层和服务越多，使用DI就越有意义。DI使得您的应用层和服务不会直接相互依赖，因此可以轻松地替换它们。此外，如果您使用Composition Root pattern并使用构造函数注入，DI通常具有非常低的开销，因此性能几乎不是一个因素。

票数 2

页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持

原文链接：

https://stackoverflow.com/questions/18796111

复制

C++11异步编程(std::async, std::future, std::packaged_task, std::promise)

c++javascript node.js http

std::async是一个函数模板，会启动一个异步任务，最终返回一个std::future对象。在之前我们都是通过thread去创建一个子线程，但是如果我们要得到这个子线程所返回的结果，那么可能就需要用全局变量或者引用的方法来得到结果，这样或多或少都会不太方便，那么async这个函数就可以将得到的结果保存在future中，然后通过future来获取想要得到的结果。async比起thread来说可以对线程的创建又有了更好的控制，比如可以延迟创建。下面先介绍一下std::future, std::packaged_task, std::promise。

Ch_Zaqdt

2020/02/15

16.1K0

C++11 std::async