在asp.net中使用依赖注入框架时有什么需要注意的吗？

Question

比如线程问题？瓶颈？记忆力有问题？

Answer 1

这取决于你对我们的框架，但总的来说，我会说不。您应该在一个线程上配置您的IoC，然后所有其他线程都将从IoC读取数据。如果您担心瓶颈或内存占用，您可以使用自己的解决方案，但大多数众所周知的解决方案都没有这些问题。

编辑:我想我应该更新这篇文章，以提供更多信息，并澄清我的答案。

这是我的观点，但DI容器的主要目的是灵活性和可测试性。从灵活的角度来看，您的业务逻辑中没有对具体实现的引用。例如，如果您的逻辑中需要一个没有DI或某个工厂的调度服务，则需要执行以下操作：

SchedulingService schedulingService = new SchedulingService();

但使用DI容器或工厂时，您将执行以下操作：

ISchedulingService schedulingService = IoC.GetInstance<ISchedulingService>();

因此，您正在对接口或基类进行编程，而不是对具体类型进行编程(您正在更新一些预定义的内容)，这意味着您可以在编译后将修改后的版本注入到该服务上。这导致了第二点，即可证明性。真正好的是，业务逻辑类甚至不会使用上面的任何一行，它只会调用它的依赖关系的方法或属性，就好像它已经知道它们一样。实现这一点的方法是在构造时将依赖项注入对象：

public UpdateDeployment(ISchedulingServer Scheduler)
{
     _scheduler = Scheduler;
}

然后可以在测试时对其进行模拟或伪造。但在您的业务逻辑中，您可以为业务对象调用一个重载的默认构造函数，该构造函数从DI容器获取依赖项，然后调用上面的构造函数：

public UpdateDeployment() : this (IoC.GetInstance<ISchedulingService>()) {}

尽管如此，从我所做的研究来看，DI容器是一个哈希表，周围围绕着一些逻辑，以帮助其配置(实际上它是一个哈希表的哈希表，但这是一个实现细节)。有关这方面的更多信息和清晰度，请查看CommonServiceLocator project on CodePlex，它定义了所有主要DI容器都支持的接口。从这个角度来看，内存占用和周期时间应该很小，但您必须考虑如何使用它。

在我工作过的项目中，我使用DI容器主要有两个原因。第一个是配置信息。一个例子是连接字符串；我知道您可以将它们放在web.config中，但这限制了您对业务逻辑的测试，因为A)您必须使用整个web堆栈，B)您必须在单元测试和集成测试之间修改文件。在我参与的项目中，我从DI容器注入了连接字符串，该容器是在global.asa中配置的，这基本上使它成为单例，如其他答案中所述。这也适用于引用类型(我知道字符串是一种引用类型，但很多人使用它们/将它们视为支持的值类型)，但您需要确保业务逻辑不会改变其状态。换句话说，它应该只使用属性的getter，或者只调用对依赖本身没有任何副作用的方法。

这导致了我使用DI的第二个原因，那就是提供服务对象。与上面的逻辑一样，SchedulingService是我正在处理的域的逻辑转储。它提供了一个服务，该服务将操作或提供业务逻辑可以使用的数据，但它本身不会更改。对自身的任何更改要么在构造时处理，要么由DI容器处理(这需要担心引用计数和锁定，这意味着它也不应该这样做)。这将解决所有线程问题，因为从业务逻辑的角度来看，容器内的数据是不可变的。

从ASP应用程序或使用访问其他依赖项的业务逻辑组件的许多客户端访问它的任何应用程序中，DI可以帮助减少内存占用大小，但它也可能损害它。例如，如果我有一个在每次请求时都需要实例化的服务(但该服务是不可变的)，那么我将拥有对象的内存占用X并发会话的数量。但是如果我有一个很少被调用的服务，我会在应用程序启动时分配内存，而它只是在那里等待使用。在我工作过的代码中，我看到的第一个比第二个更多。

希望这能有所帮助。

Answer 2

一个重要的方面是定义正确的对象生存期(单例与prototype -永远不知道这是什么正确的技术术语)，否则你可能会遇到一些讨厌的线程问题。至于瓶颈和内存问题，这些都与依赖注入框架无关，或者至少我从来没有遇到过任何与依赖注入框架相关的问题。

Answer 3

所有这些都是关注点，但无论您是否使用DI，这都是正确的。

如果要将单例注入到对象中，重要的是要确保它们的任何共享状态都是线程安全的。我参与的一个项目在web层注入了验证类。有人决定在对象中缓存一个值，而不是每次都返回数据库而不考虑线程安全。我们有一个错误的状态显示在UI中的问题，一旦我们消除了数据成员，这个问题就被修复了。