IoC 和依赖注入的实用性
在某些情况中，单元测试不不为该项目工作。
我正在研究控制反转和依赖注入实用程序，我想知道是否有充分的理由使用它而不是使单元测试更容易。
--update
好吧，让我们分析一下所提到的优点之一：更少的耦合。 您从子类型中取出耦合，并将耦合添加到需要创建要注入的对象的处理程序类型。
如果没有单元测试，这种耦合转移（而不是消除耦合）有什么好处。
There are some cases in which unit test don't work for the project.
I'm studing the Inversion of Control and Dependency Injection utilities and I would like to know if there are good reasons for use it than for make unit tests easier.
--update
Ok, let's analysis 1 of the cited advanteges: less coupling.
You take out the coupling from the child type, and you add coupling to the handler type who need to create the objects to inject.
Without unit testing, what's the advantage in this coupling transfer (not coupling eliminate).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
IOC/DI 为您的应用程序带来了一些非常重要的功能
例如：您的类可能会注入 ILog 接口，以便它可以写入日志。由于该类使用 ILog 接口，因此可以实现 FileLog、MemoryLog 或 DatabaseLog 等。将其注入到您的班级中。只要实现 ILog 接口，任何这些实现都可以正常工作
例如：考虑一个需要存储库来执行数据操作的控制器类。在这种情况下，存储库可以是控制器的 DI。如果您需要在 Controller 类上编写测试，您可以传递存储库的 DI 模拟版本，而无需使用实际的存储库类
华泰
IOC/DI bring some very important features to your application
For example: your class might get a ILog interface injected so that it can write logs. Since the class works with the ILog interface, it would be possible to implement a FileLog, MemoryLog or a DatabaseLog & inject this into your class. Any of these implementation will work fine as long as they implement the ILog interface
For example: consider a Controller class which needs a Repository to perform data operations. In this case, the repository can be DI for the controller. If you need to write tests on the Controller class, you can pass a DI'd mock version of the repository without having to work with the actual repository class
HTH
IoC 减少了耦合，这与某些中的缺陷率相关="http://books.google.com/books?id=Sduq8Y6xJeIC&pg=PA143&lpg=PA143&dq=coupling+cohesion+defect+software+rate&source=bl&ots=Lj2Q_Q3w0h&sig=be6RK- oDkdCypR6oEvfwNUzgG-Y&hl=en&ei=3xuTS7qbG5KINomw0ZIN&sa=X&oi=book_result&ct=结果&resnum=3&ved=0CBYQ6AEwAg#v=onepage&q=&f=false" rel="nofollow noreferrer" >研究。 （如果那个很长的链接不起作用，请访问 Ronald Kirk Kandt 的软件工程质量实践。）
IoC reduces coupling, which has a correlation with defect rates in some studies. (If that really long link doesn't work, it's to Software Engineering Quality Practices by Ronald Kirk Kandt.)
当然，这里有几个原因：
足够了吗？
Sure, here are a few reasons:
Enough?
来自 IoC wikipedia 文章：
虽然我认为上面的功能列表有点模糊，但即使没有测试，您也会看到上面的大部分好处。
如果我必须简而言之，我会说 IoC 显着改善了关注点分离，这是软件开发中的一个有价值的目标。
From the IoC wikipedia article:
While I would call the above feature list a bit vague, you see most of the above benefits, even without testing.
If I had to say it in a nutshell, I would say that IoC significantly improves separation of concerns which is a valuable goal in software development.
是的，依赖注入可以帮助您使您的类更加集中、更清晰*并且更容易更改，因为它可以更轻松地遵守 单一责任原则。
它还使您可以更轻松地相互独立地改变应用程序的各个部分。
特别是当您使用构造函数注入时，可以更轻松地了解代码需要执行的操作它的工作。如果
WeatherUpdater类在其构造函数中需要一个IWeatherRepository，那么没有人会对它使用数据库感到惊讶。* 再次强调，仅限构造函数注入。
Yes, dependency injection helps you make your classes more focused, clearer*, and easier to change, because it makes it easier to adhere to the single-responsibility principle.
It also makes it easier to vary parts of your application independently of one another.
When you use constructor injection in particular, it's easier to tell what your code needs to do its job. If the
WeatherUpdaterclass requires anIWeatherRepositoryin its constructor no one is surprised that it uses a database.* Again, constructor injection only.