Both your questions concern controversial topics, but I'll weigh in on my side of the debates.
If you decide to use an IoC container, is it meant to be used everywhere in the application, only where you have many inverted dependencies to resolve, or only in the consumer?
Your top-level application (the consumer) is the only component that should know about your dependency injection framework. You don't need to replace new throughout your codebase because each object should have all the dependency instances it needs to do its job (Miško Hevery's "Dependency Injection Myth: Reference Passing" was what finally drove this home for me).
Is it considered good or bad to have every class (where possible, of course) derive from an interface whether or not there's a need to use DI/IoC or something like mocking it?
The rest of this question shows that you already know the answer to this: only build interfaces to create more suitable abstractions (than the concrete class in question) or to provide some other value.
I'm currently working deeply with DI/IoC in C#/WinForm on VisualStudio2010/12. My choise fall on Castle Windsor, but also StructureMap but is not important what IoCC you use.
For a very detailed answer I suggest you to read "Dependency Injection in .NET" by Mark Seemann. That is a good book even if you do not develop in .NET.
Regarding your questions:
A DI CONTAINER is a library that you can potentially use from wherever you would like—but that doesn’t mean that you should. Although you can spread out the use of the container so that it permeates a large percentage of your classes, you should instead concentrate it into a single area of your application.
This place is called the COMPOSITION ROOT and you should only use a DI CONTAINER from within that place. The COMPOSITION ROOT of the application should be located in the application’s root so that it can properly compose the application. You shouldn’t attempt to compose classes in any of the modules because that approach limits your options. All classes in application modules should use CONSTRUCTOR INJECTION (or, in rare cases, one of the other patterns like Property Injection) and leave it up to the COMPOSITION ROOT to compose the application’s object graph. Any DI CONTAINER call should be limited to the COMPOSITION ROOT.
The COMPOSITION ROOT can be spread out across a few classes. This is expected—the important thing is that all classes are contained in the same module, which preferebly is the application root.
You are not required to use interfaces everywhere. You can also use concrete classes. Certainly interfaces provide a higher level of abstraction, but you have to consider if you need in your project. For example, it is good practice to use the interface in the business logic in your application.
发布评论
评论（2）
你的两个问题都涉及有争议的话题，但我会在辩论中发表我的观点。
您的顶级应用程序（使用者）是唯一应该了解依赖项注入框架的组件。您不需要在整个代码库中替换
new，因为每个对象都应该拥有完成其工作所需的所有依赖项实例（Miško Hevery 的“依赖注入神话：引用传递"最终让我明白了这一点）。这个问题的其余部分表明您已经知道这个问题的答案：仅构建接口来创建更合适的抽象（比相关的具体类）或提供一些其他值。
Both your questions concern controversial topics, but I'll weigh in on my side of the debates.
Your top-level application (the consumer) is the only component that should know about your dependency injection framework. You don't need to replace
newthroughout your codebase because each object should have all the dependency instances it needs to do its job (Miško Hevery's "Dependency Injection Myth: Reference Passing" was what finally drove this home for me).The rest of this question shows that you already know the answer to this: only build interfaces to create more suitable abstractions (than the concrete class in question) or to provide some other value.
我目前正在 VisualStudio2010/12 上的 C#/WinForm 中深入研究 DI/IoC。
我的选择是 Castle Windsor，还有 StructureMap，但使用什么 IoCC 并不重要。
对于非常详细的答案，我建议您阅读 Mark Seemann 的“.NET 中的依赖注入”。即使您不使用 .NET 进行开发，这也是一本好书。
关于您的问题：
A DI CONTAINER 是一个您可以从任何地方使用的库
喜欢——但这并不意味着你应该这样做。虽然您可以分散使用
容器，以便它渗透到您的大部分类中，您应该
相反，将其集中到应用程序的单个区域中。
这个地方叫做
组合根目录，您应该只使用该位置中的 DI 容器。
应用程序的 COMPOSITION ROOT 应位于应用程序的
root 以便它可以正确地编写应用程序。
您不应该尝试在任何模块中编写类，因为
方法限制了你的选择。应用程序模块中的所有类都应使用 CONSTRUCTOR
注入（或者在极少数情况下，其他模式之一，如属性注入）并将其留给组合根来组合应用程序的对象图。任何DI容器
调用应仅限于 COMPOSITION ROOT。
COMPOSITION ROOT 可以分布在几个类中。
这是预期的——重要的是所有类都包含在同一个中
模块，最好是应用程序根目录。
您不需要在任何地方都使用接口。您还可以使用具体类。当然，接口提供了更高级别的抽象，但是您必须考虑您的项目中是否需要。例如，在应用程序的业务逻辑中使用接口是一种很好的做法。
I'm currently working deeply with DI/IoC in C#/WinForm on VisualStudio2010/12.
My choise fall on Castle Windsor, but also StructureMap but is not important what IoCC you use.
For a very detailed answer I suggest you to read "Dependency Injection in .NET" by Mark Seemann. That is a good book even if you do not develop in .NET.
Regarding your questions:
A DI CONTAINER is a library that you can potentially use from wherever you would
like—but that doesn’t mean that you should. Although you can spread out the use of
the container so that it permeates a large percentage of your classes, you should
instead concentrate it into a single area of your application.
This place is called the
COMPOSITION ROOT and you should only use a DI CONTAINER from within that place.
The COMPOSITION ROOT of the application should be located in the application’s
root so that it can properly compose the application.
You shouldn’t attempt to compose classes in any of the modules because that
approach limits your options. All classes in application modules should use CONSTRUCTOR
INJECTION (or, in rare cases, one of the other patterns like Property Injection) and leave it up to the COMPOSITION ROOT to compose the application’s object graph. Any DI CONTAINER
call should be limited to the COMPOSITION ROOT.
The COMPOSITION ROOT can be spread out across a few classes.
This is expected—the important thing is that all classes are contained in the same
module, which preferebly is the application root.
You are not required to use interfaces everywhere. You can also use concrete classes. Certainly interfaces provide a higher level of abstraction, but you have to consider if you need in your project. For example, it is good practice to use the interface in the business logic in your application.