我对仓库和依赖注入还不熟悉，正在尝试在我的MVC 5项目中实现。
我实现了构造函数注入，在我的控制器中有一个像这样的构造函数:
IBook _ibook;
public Test(IBook ibook)
{
_ibook = ibook;
}
没有任何依赖注入库，它会抛出错误：没有空构造函数。
为了避免这种情况，我添加了以下一个构造函数：
public Test ():this(new Book())
{
}
因为我对DI不熟悉，所以我不想冒险使用可能会在以后引发一些我无法解决的错误的DI库来进行我的项目。
我想知道如果我不使用DI库会遇到什么问题。
如果推荐使用，哪个DI库适合初学者？我看过NInject和Unity的一些视频。
在使用工具或库之前，推荐延迟决策直至最后负责时机。通过良好的设计，可以随后添加依赖注入库，这意味着你在实践纯 DI。
MVC 的首选拦截点是 IControllerFactory 抽象类，因为它允许你拦截 MVC 控制器的创建，并且这样做可以避免你必须实现第二个构造函数（这是一个反模式）。虽然可以使用 IDependencyResolver，但使用该抽象类要麻烦得多，因为它还会被 MVC 调用以解决通常不感兴趣的问题。
以下是实现作为 组合根 的自定义 IControllerFactory：
public sealed class CompositionRoot : DefaultControllerFactory
{
private static string connectionString =
ConfigurationManager.ConnectionStrings["app"].ConnectionString;
private static Func<BooksContext> bookContextProvider = GetCurrentBooksContext;
private static IBookRepository bookRepo = new BookRepository(bookContextProvider);
private static IOrderBookHandler orderBookHandler = new OrderBookHandler(bookRepo);
protected override IController GetControllerInstance(RequestContext _, Type type) {
// Unfortunately, because of MVC's design, controllers are not stateless, and
// you will have to create them per request.
if (type == typeof(OrderBookController))
return new HomeController(orderBookHandler);
if (type == typeof(BooksController))
return new BooksController(bookRepo);
// [other controllers here]
return base.GetControllerInstance(_, type);
}
private static BooksContext GetCurrentBooksContext() {
return GetRequestItem<BooksContext>(() => new BooksContext(connectionString));
}
private static T GetRequestItem<T>(Func<T> valueFactory) where T : class {
var context = HttpContext.Current;
if (context == null) throw new InvalidOperationException("No web request.");
var val = (T)context.Items[typeof(T).Name];
if (val == null) context.Items[typeof(T).Name] = val = valueFactory();
return val;
}
}
public class MvcApplication : System.Web.HttpApplication
{
protected void Application_Start() {
ControllerBuilder.Current.SetControllerFactory(new CompositionRoot());
// the usual stuff here
}
}
BooksContext）不应通过构造函数注入。在示例中，我使用了一个Func<T>作为BooksContext的提供者，该提供者存储在每个请求中。BooksContext的每个请求生命周期。尽管所有的DI库都支持像每个请求这样的范围生命周期，但我会反对使用这些范围生命周期（除非库保证抛出异常而不是静默失败）。大多数库在您解析活动范围之外的范围实例时不会警告您（例如，在后台线程上解析每个请求的实例）。一些容器将返回单例实例，其他容器将每次都返回一个新实例。这真的很麻烦，因为它隐藏了错误，并可能导致您花费许多时间调试应用程序（我在这里说话的经验）。GetControllerInstance 来最轻松地完成。protected override IController GetControllerInstance(
RequestContext requestContext, Type controllerType)
{
if (controllerType == typeof(Test))
return new Test(new Book());
return base.GetControllerInstance(requestContext, controllerType);
}
然后像这样在您的 Global.asax 中注册新的控制器工厂：
ControllerBuilder.Current.SetControllerFactory(new MyControllerFactory());
不幸的是，许多文档会告诉你使用IDependencyResolver或混合注入来处理依赖注入，但这些做法并不能使你的代码更易维护。
关于如何在ASP.NET MVC中正确使用依赖注入，以及更多详细信息，请参见我的书。
internal class MyBasicResolver : IDependencyResolver
{
private readonly Dictionary<Type, Type> _services = new Dictionary<Type, Type>()
{
{ typeof(IBook), typeof(Book) }
// more services registrations
};
public object GetService(Type serviceType)
{
return _services.ContainsKey(serviceType) ? Activator.CreateInstance(_services[serviceType]) : null;
}
public IEnumerable<object> GetServices(Type serviceType)
{
yield return GetService(serviceType);
}
}
然后将其注册为MVC的当前依赖项解析器：
DependencyResolver.SetResolver(new MyBasicResolver());
见MSDN
Ninject和Unity提供对象容器，其中包含在应用程序启动时注册的对象。
但是为什么需要使用依赖注入（DI）呢？DI表示两个对象不应该依赖于其具体实现，而应该依赖于其抽象。因此，如果将来需要将Book类替换为eBook，这两个类具有相同的功能，但具有不同的具体实现，那么您只需要调整DI配置，而无需重新编写eBook的控制器。
我在大多数项目中都使用Unity DI，我没有遇到任何无法解决的问题，它很容易使用并且是一种好的实践方法，不要害怕使用它。