在应用程序扩展性的预期中使用IoC容器

我知道还有类似的问题Here但我认为我的这个扩展了一点。在应用程序扩展性的预期中使用IoC容器

我最近一直在研究已经生产了大约一年的应用程序，没有问题，也没有真正的扩展计划。该应用程序具有很少依赖性，并使用DI但没有容器。

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

我作为我前进的具体问题是：

在规划和编码想必不会扩大小很多的应用程序，我应该实现的容器在期待那个场景，如这些可能存在自己和这样的期待，我会更好地从一开始就实施一个容器，因此在扩展时已经存在框架。
如果在将应用程序扩展到超出其初始意图时执行容器变得繁琐，那么这是设计不佳的标志吗？

编辑：

我使用固体原则（尽我的能力），并在我的应用广泛的接口目前的问题是，更关系到在使用IoC容器，而不是DI的和它本身。前面提到的应用程序是一种自带的DI样式，我正在添加一个容器，问题出现在这个容器中。

来源

2014-02-06 Evan L

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

如果为将来的扩展性准备项目现在花费时间或金钱，请不要这样做。你可以在将来支付。因为未来可能永远不会到来。如果确实如此，那肯定不会像预测的那样，你的准备也不会像你想象的那样有用。

我一直在那些有很多“可扩展性”代码的项目中，您至少可以删除75％的源代码，并且所有必需的功能仍然存在。我没有想到项目经理想知道为了实现这样一个基本功能而花了那么长时间。不要这样做。规划您的项目，获取您的要求并实施它们。如果可扩展性是一项要求，那么计划它，估算它，让你的经理知道。我的猜测是他们不希望可扩展性太差。他们宁愿有另一个工作计划。

这就是说，显然你在学习。如果它不花费时间和金钱，请继续开发下一个程序，以便更容易地扩展。只要留意成本。

来源

2014-02-06 15:42:34 nvoigt

我知道YAGNI会上来，这正是我引起这个问题的原因。我同意成本绝对是一个因素，但正如在其他答案中所述，将容器添加到小应用程序的开销很小，我同意，因为我以前做过这件事，而且它很简单。在你看来，你会如何定义YAGNI的“需求”？没有任何代码需要*容器，但它肯定可以提高可管理性。否则，我完全同意你的第三段。如果实施成本高昂，您可以让您的经理们思考如此长的时间。 –

就Yagni而言，如果我的项目没有从某些方面获得直接利益，那就不需要了。例如，DI使我的项目单元测试更容易。所以我需要它。容器不会授予任何额外的好处，因为除了生产使用和硬编码单元测试之外，我不需要切换实现。因此不需要添加容器。其他人可能有不同的要求，所以他们会针对各自的项目得出不同的结论。 – nvoigt

DI不仅有助于单元测试。它还有助于松散耦合和关注点分离。从用户的角度来看，这不是直接的要求，但它们很重要。无论你需要一个容器是另一个问题，但我通常更喜欢经过测试和维护的解决方案，而不是你自己的。 – Kenneth

我认为在即使是最小的应用程序中使用DI也是有益的，并且有很少的缺点（开销非常小）。使用容器可能总是比滚动更快（更不用说更稳定）了。
理想情况下，如果您应用了坚实的原则并针对接口进行编程，而不是具体类型，则只需修改组合根。这意味着你一直在使用DI而没有容器，并且有DIY解决方案。如果不是，那么转向DI可能会更难一些。

我建议不要一次性处理整个重构。以小增量逐步进行并随时测试。这是最高的机会不打破任何现有的功能，它会让你在应用程序的整体设计中发现错误

来源

2014-02-06 15:24:55 Kenneth

非常感谢您的回答以及关于逐步重构的反馈。 –

1. When planning and coding smaller applications that presumably will not expand much, should I implement a container in anticipation that scenarios such as these may present themselves and in such anticipation I would be better off implementing a container from the start so upon extension the framework already exists。

为什么不定位自己未来的成功？即使在一个小应用程序中，好处也很多，而且额外的工作量很小。

2. Is it a sign of poor design if implementing a container when extending an application beyond its original intention becomes cumbersome?

有些人可能会争辩说，设计最初由于没有使用容器而很差。你可能会改进设计，所以如果做得对，这不会是件坏事。初衷是什么？要紧密耦合，难以测试？我说，继续你的想法。

顺便说一句，如果你不使用接口的无偿使用，目前，我建议这是一个很好的开始。

来源

2014-02-06 15:44:03

比较手动进样和自动注射：

1）

作为另一个答复中提到，使用容器从一开始就为未来的打样解决方案在我看来是一个好主意。不过，我强烈建议用一个好的编码标准文件来跟进这个过程。为了说明这一点，请查看我在生产系统中看到的以下代码。

public class MyClass 
{ 
IUnityContainer _container; 
public MyClass(IMyDependentInterface dpenedentclass, IUnityContainer container) 
{ 
_container = container; 
//........ 
} 

public void DoSomething() 
{ 
    var obj = _container.Resolve<ISomeOtherInterface>(); 
    obj.DoAction();  
}  
}

不知不觉中在这里建立了一个反模式（服务定位器？）。正如你所看到的，在这个世界上似乎没有失效证明的设计。所以，不要犹豫，在您的编码标准文件中添加看似明显的内容。

2）

如果移动到自动注射是困难的，它是一件坏事的标志。它可以是设计，但不会低估前面说明的糟糕设计糟糕设计的力量。

来源

2014-02-06 17:46:50 Jimmy

感谢您的回答，我知道早期实施易*且需要很少的开销 - 我将来可能会朝着这个方向发展，因为我的组织总是喜欢为我的软件提供*好点子* =） –

在应用程序扩展性的预期中使用IoC容器

回答

相关问题