IoC 容器如何实现依赖注入与我的实现方式相比
为了进行依赖注入，我可以创建一个不同类型的数据库连接的通用字典，然后通过反射动态实例化一种类型，然后将其传递给需要它的对象的构造函数。
使用 IOC 容器时它会带来什么区别和好处，因为它不会使我的东西比第一个解决方案更加独立。 IOC 容器内部如何运作？与第一个解决方案有什么不同吗？
如果没有容器，你将如何实现 DI？您什么时候会切换到 IoC 容器？
我的意思是，除了我考虑过的方法之外，是否还有其他方法来实现 DI，以便我可以使用最好的方法？
To do Dependency Injection, I could create a generic dictionary of different types of db connections and then instantiate one type dynamically through reflection before passing it to the object's constructor that needs it.
What difference and benefit does it bring when using an IOC Container since It doesn't make my stuff more independant than the first solution. How the IOC Container would do internally ? Is it different from the first solution ?
How would you implement DI without container ? When would you switch to an IoC Container ?
I mean is there other way to implement DI other than the one I have thought about so that I could use the best way ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我想容器会为您完成很多样板代码。例如，它完全按照您所说的操作，根据反映的行为实例化一个类。许多容器还允许您根据配置文件显式配置系统。
IOC或DI只是概念。 IOC/DI 概念为您提供您所青睐的“独立性”。实际的实施可能会有所不同。您可以在不使用第三方容器的情况下完成此操作，或者编写自己的容器。或者，您可以利用经过充分测试的第三方容器提供的功能。
如果您只想注入不同类型的数据库连接，那么您对 IOC/DI 的需求非常小。一般来说，IOC/DI（注意，不是容器，它只是 IOC/DI 的实现）为您提供完全可配置的软件，有助于单元测试（通过注入存根）、自配置等 通常，在以下情况下，
IOC/DI 是必要的：
I suppose a container does a lot of the boiler-plate code for you. For example, it does exactly what you said, instantiating a class based on the reflected behavior. Many containers also allow you to explicitly configure your system based on config files.
IOC or DI are only concepts. IOC/DI concepts give you the "indenpendency" that you favor. The actual implementation can vary. You can do it without using a third-party container -- or write your own. Or you can leverage the features provided by a well-tested third-party container.
If you just want to inject different types of db connections, they you have a very small need for IOC/DI. In general IOC/DI (beware, not the container, which is just an implementation of IOC/DI) gives you totally configurable software, aids in unit testing (by injecting stubs), self-configuration, etc.
Typically IOC/DI is necessary when:
依赖注入与字典无关。正如 Nicholas Blumhardt 在一篇出色的博客文章中所解释的那样，您需要一个完全DI 的不同思维模型。
DI 通过应用构造函数注入和组合根设计模式实现松耦合。当 DI 容器进入画面时，它通过 Register Resolve Release 进行操作图案。
因此，如果一个类需要数据库连接，它会通过构造函数请求一个。
Dependency Injection has nothing to do with dictionaries. As Nicholas Blumhardt explains in an excellent blog post, you need a completely different mental model for DI.
DI is loose coupling through the application of the Constructor Injection and Composition Root design patterns. When a DI Container enters the picture it does so via the Register Resolve Release pattern.
So if a class requires a db connection, it requests one through the constructor.
没有什么说你需要使用 IoC 容器，只是 IoC 容器是预先构建的，你不必自己编写代码。这意味着您可以专注于构建您的应用程序，而不是您自己的 DI 系统。
这就像构建 UI 或使用第三方控件一样。两者都有效，只是取决于您想把时间花在哪里。我知道我不太关心构建自己的 DI 系统，所以我宁愿使用预构建的系统。
您可能会问，当您可以直接写入操作系统 API 时，为什么还要使用框架呢？这一切都是为了提高可靠性（通过重用其他人已经编写的代码并花费大量时间确保没有错误）和提高您的生产力（不必自己编写所有内容）。
编辑：
有很多方法可以实现 DI。您始终可以查看现有的所有容器以及它们的工作原理。它们都是开源的，并且源代码可用。
Nothing says you need to use an IoC container, it's just that IoC containers are pre-built, and you don't have to write the code yourself. This means you can concentrate on building your app, and not your own DI system.
It's like building your UI or using a third party control. Both work, it just depends on where you want to spend your time. I know I don't really care much about building my own DI system, so I would rather use a pre-built one.
You might as well ask, why use a framework at all when you can write directly to the OS APIs. It's all about improving reliability (by reusing code someone else has already written and spent lots of time making sure was bug free) and boosting your productivity (by not having to write everything yourself).
EDIT:
There are lots of ways to implement DI. You could always look at all the containers that are out there, and how they work. They're all open source, and the source code is available.