问题描述
这几天看Kephas框架时，我注意到它提供了自己的依赖项注入容器。现在市场上有很多依赖注入框架，为什么要自己实施呢？
When taking a look at Kephas framework these days, I noticed it provides its own dependency injection container. There are so many dependency injection frameworks on the market now, why bring your own implementation? Isn't that just reinventing the wheel?
推荐答案
Kephas本身并没有提供DI / IoC容器，而是仅提供了一种抽象方法？层位于DI / IoC容器之上，因此它可以使用合成本身，而不必绑定到特定的实现。它确实提供的是Kephas.Composition.Mef包（System.Composition 这个抽象层的适配器。 org / packages / Kephas.Composition.Mef / rel = nofollow noreferrer> https://www.nuget.org/packages/Kephas.Composition.Mef/ ）。我们还计划了 Autofac 的适配器，但我们没有时间实现它。
Kephas does not provide a DI/IoC container itself, it provides only an abstraction layer over DI/IoC containers, so that it can use composition itself without being bound to a specific implementation. What it does provide is an adapter for this abstraction layer for System.Composition in the Kephas.Composition.Mef package (https://www.nuget.org/packages/Kephas.Composition.Mef/). We planned also an adapter for Autofac but we didn't have the time to implement it to end.
请请注意，此抽象层确实具有Kephas独有的一些功能：
Please note that this abstraction layer does come with some features unique to Kephas:
- 注册服务实现可能会被覆盖，以利用分层的应用程序体系结构。 / li>
- 服务合同/接口通过
[* AppServiceContract]属性来驱动注册。
- Registered service implementations may be overridden, to leverage layered application architectures.
- Service contracts/interfaces drive the registration by the means of the
[*AppServiceContract]attributes.
还请注意，元数据支持是Kephas集成的DI框架的必需功能，在某些情况下可能会施加限制。有关更多信息，您可以在这里阅读：。
Also note that metadata support is a required feature for DI frameworks Kephas integrate with, which, in some cases, may impose limitations. For more information you can read here: https://github.com/kephas-software/kephas/wiki/Composition-and-Dependency-Injection.
这篇关于Kephas有自己的可靠注射容器。为什么要使用另一个框架，为什么不使用现有框架呢？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！