c# - 在预期应用程序可扩展性中使用 IoC 容器

Question

我知道有一个类似的问题Here但我认为我的内容对此进行了更多扩展。

我最近一直在开发一个已经投入生产大约一年的应用程序，没有任何问题，也没有真正的扩展计划。该应用程序几乎没有依赖项并使用 DI 但没有容器。

现在我正在按照公司的指示将应用程序扩展到更广泛的范围，这促使我实现了 IoC 容器的使用。这里的问题是将容器添加到我以前认为永远不需要的代码的开销。

我前进的具体问题是:

1. 在计划和编写可能不会扩展太多的较小应用程序时，我是否应该实现一个容器，因为预计可能会出现这些情况，并且在这种情况下，我最好从一开始就实现一个容器，以便扩展后框架已经存在。

2. 如果在超出其初衷扩展应用程序时实现容器变得麻烦，这是否是设计不良的标志？

编辑:

我目前正在我的应用程序中广泛使用可靠的原则(尽我所能)和接口(interface)，问题更多地与 IoC 容器的使用有关，而不是 DI 本身。前面提到的应用程序是一种自己动手的 DI 样式，我正在向其中添加一个容器，这是问题出现的地方。

Answer 1

我是 Clean Code 的忠实粉丝，尤其是 YAGNI。 “你不会需要它”。如果项目中不需要 DI，请不要使用它。如果您需要 DI 进行单元测试但不需要容器，请不要使用容器。简单是它自己的优点。保持尽可能简单。

如果现在为 future 的可扩展性准备项目会花费时间或金钱，请不要这样做。你可以在未来支付。因为那个 future 可能永远不会到来。如果真的发生了，它肯定不会像预期的那样，你的准备也不会像你想象的那样有用。

我参与过的项目中有太多“可扩展性”代码，您可以删除至少 75% 的源代码，而所有必需的功能仍然存在。我可以想象项目经理想知道到底花了这么长时间才实现这样一个基本功能。不要那样做。计划您的项目，获取您的要求并实现它们。如果可扩展性是一项要求，请对其进行计划、估计，并让您的经理知道。我的猜测是他们非常不想要可扩展性。他们宁愿有另一个工作程序。

也就是说，显然您正在学习。如果它在时间或金钱方面没有任何成本，请继续开发您的下一个程序，以便更轻松地扩展它。只需关注成本即可。