我一直在研究.NET的各种依赖注入框架,因为我觉得我正在开发的项目将从中受益匪浅。虽然我认为我已经很好地掌握了这些框架的功能,但我仍然不清楚如何最好地将它们引入大型系统。大多数演示(可以理解)往往是具有一个或两个依赖关系的非常简单的类。
我有三个问题......
首先,您如何处理那些常见但无趣的依赖关系,例如ILog,IApplicationSettings,IPermissions,IAudit。对于每个类来说,在构造函数中将这些作为参数似乎有点过分了。在需要时使用DI容器的静态实例来获取它们会更好吗?
MyClass(ILog log, IAudit audit, IPermissions permissions, IApplicationSettings settings)
// ... versus ...
ILog log = DIContainer.Get<ILog>();
其次,如何处理可能使用的依赖项,但创建起来可能很昂贵。示例 - 类可能依赖于ICDBurner接口,但不希望创建具体实现,除非实际使用了CD刻录功能。你是否在构造函数中将接口传递给工厂(例如ICDBurnerFactory),或者你是否再次使用一些静态的方法直接进入DI容器并在需要时询问它?
第三,假设您有一个大型Windows窗体应用程序,其中顶级GUI组件(例如MainForm)可能是数百个子面板或模态窗体的父级,每个子窗格或模式窗体可能具有多个依赖关系。这是否意味着应该将MainForm设置为具有其子项的所有依赖项的超集作为依赖项?如果你这样做了,最终是否会创建一个巨大的自我膨胀怪物来构建你创建MainForm时可能需要的每一个类,在这个过程中浪费时间和记忆?
第一步:根据需要将简单依赖项添加到构造函数中。没有必要为每个构造函数添加每个类型,只需添加您需要的类型。需要另一个,只需展开构造函数。性能不应该是一件大事,因为大多数这些类型可能是单身人士,因此在第一次通话后已经创建。不要使用静态DI容器来创建其他对象。而是将DI容器添加到自身,以便它可以将自身解析为依赖关系。所以这样的事情(暂时假设Unity)
IUnityContainer container = new UnityContainer();
container.RegisterInstance<IUnityContainer>(container);
这样您就可以在IUnityContainer上添加一个依赖项,并使用它来创建昂贵或很少需要的对象。主要优点是单元测试更容易,因为没有静态依赖。
第二:无需通过工厂课程。使用上述技术,您可以使用DI容器本身在需要时创建昂贵的对象。
三:将DI容器和轻型单件依赖项添加到主窗体,并根据需要通过DI容器创建其余部分。需要更多代码,但正如您所说,如果您在启动时创建所有内容,则主体的启动成本和内存消耗将会达到顶峰。
好吧,虽然您可以按照其他答案中的描述执行此操作,但我相信对于您的示例有更重要的事情需要回答,那就是您可能违反了SRP原则,并且具有许多依赖关系的类。
我在你的例子中会考虑的是在几个更连贯的类中分解类,并且关注的问题因此依赖的数量会下降。
尼古拉的SRP和DI法则
“任何有超过3个依赖关系的类都应该被质疑是否存在SRP违规行为”
(为了避免冗长的回答,我在IoC and SRP博客文章中详细介绍了我的答案)
第一:
您可以在需要时将这些对象作为成员而不是在构造函数中注入。这样,您不必在使用情况发生变化时对构造函数进行更改,也不需要使用静态。
第二:
通过某种建设者或工厂。
第三:
任何类都应该只有它自己需要的依赖项。子类应该注入自己的特定依赖项。
我有一个类似的案例涉及“昂贵的创建和可能被使用”,在我自己的IoC实现中,我正在为工厂服务添加自动支持。
基本上,而不是这个:
public SomeService(ICDBurner burner)
{
}
你会这样做:
public SomeService(IServiceFactory<ICDBurner> burnerFactory)
{
}
ICDBurner burner = burnerFactory.Create();
这有两个好处:
工厂对象很容易制作,并解决了很多问题。
这是我的工厂类:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using LVK.IoC.Interfaces;
using System.Diagnostics;
namespace LVK.IoC
{
/// <summary>
/// This class is used to implement <see cref="IServiceFactory{T}"/> for all
/// services automatically.
/// </summary>
[DebuggerDisplay("AutoServiceFactory (Type={typeof(T)}, Policy={Policy})")]
internal class AutoServiceFactory<T> : ServiceBase, IServiceFactory<T>
{
#region Private Fields
[DebuggerBrowsable(DebuggerBrowsableState.Never)]
private readonly String _Policy;
#endregion
#region Construction & Destruction
/// <summary>
/// Initializes a new instance of the <see cref="AutoServiceFactory<T>"/> class.
/// </summary>
/// <param name="serviceContainer">The service container involved.</param>
/// <param name="policy">The policy to use when resolving the service.</param>
/// <exception cref="ArgumentNullException"><paramref name="serviceContainer"/> is <c>null</c>.</exception>
public AutoServiceFactory(IServiceContainer serviceContainer, String policy)
: base(serviceContainer)
{
_Policy = policy;
}
/// <summary>
/// Initializes a new instance of the <see cref="AutoServiceFactory<T>"/> class.
/// </summary>
/// <param name="serviceContainer">The service container involved.</param>
/// <exception cref="ArgumentNullException"><paramref name="serviceContainer"/> is <c>null</c>.</exception>
public AutoServiceFactory(IServiceContainer serviceContainer)
: this(serviceContainer, null)
{
// Do nothing here
}
#endregion
#region Public Properties
/// <summary>
/// Gets the policy that will be used when the service is resolved.
/// </summary>
public String Policy
{
get
{
return _Policy;
}
}
#endregion
#region IServiceFactory<T> Members
/// <summary>
/// Constructs a new service of the correct type and returns it.
/// </summary>
/// <returns>The created service.</returns>
public IService<T> Create()
{
return MyServiceContainer.Resolve<T>(_Policy);
}
#endregion
}
}
基本上,当我从我的服务容器构建器类构建服务容器时,所有服务注册都会自动获得另一个协同服务,为该服务实现IServiceFactory,除非程序员已明确在他/她自己注册该服务。然后使用上述服务,其中一个参数指定策略(如果不使用策略,则可以为null)。
这允许我这样做:
var builder = new ServiceContainerBuilder();
builder.Register<ISomeService>()
.From.ConcreteType<SomeService>();
using (var container = builder.Build())
{
using (var factory = container.Resolve<IServiceFactory<ISomeService>>())
{
using (var service = factory.Instance.Create())
{
service.Instance.DoSomethingAwesomeHere();
}
}
}
当然,更典型的用途是使用CD Burner对象。在上面的代码中,我将解决该服务,而不是当然,但它是一个例子,说明发生了什么。
因此,使用您的CD刻录机服务:
var builder = new ServiceContainerBuilder();
builder.Register<ICDBurner>()
.From.ConcreteType<CDBurner>();
builder.Register<ISomeService>()
.From.ConcreteType<SomeService>(); // constructor used in the top of answer
using (var container = builder.Build())
{
using (var service = container.Resolve<ISomeService>())
{
service.Instance.DoSomethingHere();
}
}
在服务内部,您现在可以拥有服务,工厂服务,该服务知道如何根据请求解析您的CD刻录机服务。这有用的原因如下:
这是两个同时:
using (var service1 = container.Resolve<ISomeService>())
using (var service2 = container.Resolve<ISomeService>())
{
service1.Instance.DoSomethingHere();
service2.Instance.DoSomethingHere();
}
这是彼此之后的两个,而不是重用相同的服务:
using (var service = container.Resolve<ISomeService>())
{
service.Instance.DoSomethingHere();
}
using (var service = container.Resolve<ISomeService>())
{
service.Instance.DoSomethingElseHere();
}
第一:
你可以通过创建一个容器来保存你的“无趣的”依赖关系(ILog,ICache,IApplicationSettings等),然后使用构造函数注入来注入它,然后在构造函数内部,从container.Resolve中水合服务的字段。 )?我不确定我是否喜欢这样,但是,这是一种可能性。
或者,您可能希望使用新的IServiceLocator通用接口(http://blogs.msdn.com/gblock/archive/2008/10/02/iservicelocator-a-step-toward-ioc-container-service-locator-detente.aspx)而不是注入依赖项?
第二:
您可以将setter注入用于可选/按需依赖项吗?我想我会按需要注入工厂和新工厂。
为了部分回答我的第一个问题,我刚刚找到了Jeremy Miller的blog post,展示了如何使用Structure Map和setter注入来自动填充对象的公共属性。他以ILogger为例:
var container = new Container(r =>
{
r.FillAllPropertiesOfType<ILogger>().TheDefault.Is
.ConstructedBy(context => new Logger(context.ParentType));
});
这意味着任何具有ILogger属性的类,例如:
public class ClassWithLogger
{
public ILogger Logger { get; set; }
}
public class ClassWithLogger2
{
public ILogger Logger { get; set; }
}
将在构造时自动设置其Logger属性:
container.GetInstance<ClassWithLogger>();