将依赖注入与来自NuGet包的策略一起使用是否被认为是一个良好的实践？

Question

我正在开发一个NuGet包，其中包含各种ASP.NET核心项目的共享代码。我计划使用策略模式，以几种不同的方式解决同样的问题。因此，将有几个公共接口的不同实现。见- https://deviq.com/design-patterns/strategy-pattern

我的问题是，这个包的消费者是否应该通过在IoC容器中注册来选择他们希望使用的具体策略？我知道有些NuGet包只是使用静态方法(例如JsonConvert.DeserializeObject)，但我想避免这种情况，因为我有多个、有效的、不同的实现，我希望包的使用者能够在它们之间进行选择。

Answer 1

你的图书馆应该是独立的。它应该在没有任何类型的依赖注入容器的情况下工作，因为这是应用程序的实现细节，库应该不在乎。

我想许多人会喜欢的是，如果您可以使用单独的包和特定的DI技术来发布另一个包，而不是您的文档中关于如何使用带有特定依赖项注入容器的库的示例，并提供完成所有连接的辅助函数，我想很多人都会很感激。

这样的话，如果我确实使用了对大多数应用程序默认的ServiceCollection，那么对于您的附加程序包，我有一种简单的方法，但是如果我使用另一种机制，或者甚至根本不使用，我仍然可以包括您的包，而不必担心您带来的所有依赖关系，这些都是我明确不想使用的。

这是一种常见的模式。

假设您将包命名为"MyCoolAlgorithm“，那么您就可以拥有一个包"MyCoolAlgorithm.Unity”或"MyCoolAlgorithm.ServiceCollection“，或者您希望为人们提供的任何其他容器技术，从而使使用该技术的库更容易使用。

Answer 2

我有多个、有效的、不同的实现，我希望包的使用者能够在它们之间进行选择。

好的。

这个包的消费者是否应该通过向IoC容器注册来选择他们希望使用的特定策略？

什么IoC容器？我不需要什么臭容器使用NuGet，策略模式，或者选择我自己的“不同实现”。

哦我看到问题了。您需要一个更好的战略模式示例。这是在C#的一个，实际上是news 在它们所属的调用堆栈的高处。

当从库中访问它们时，它们并没有太大的不同：

注意，这看起来有点像策略模式图吗？这是一个相当受欢迎的图书馆。

这些ISomething类型中的任何一个都可以代表Strategy。灰色盒子可以代表ConcreteStrategies。唯一缺少的是Context。你可以把它作为练习留给你的用户。或者你对Context有一些想法。好吧，让库用户构建这些具体类型之一，并将其交给您。

策略模式的重要之处在于，您不必在编译时知道所使用的是什么。这肯定不是有人说服您使用的IoC容器。

Answer 3

为什么你有多种策略？这里有两种选择：

一个人普遍优于另一个人。

在这种情况下，您可以安全地丢弃所有其他的，并默认使用上级的。

B他们各有长处和短处。

这是保持多种策略的正当理由。考虑到每种策略的利弊不同，您的消费者将希望选择最适合他们的用例的策略。

我建议选择这个选项。提供默认实现，但当使用者选择时，则使其变得可重写。