服务定位器和依赖注入

时间:2014-05-10 16:30:25

标签: c# dependency-injection inversion-of-control

我认为普遍认为以下是不好的

public class Foo
{
    private IService _service;
    public Foo()
    {
        _service = IocContainer.Resolve<IService>();
    }
}

以下是首选(依赖注入)

public class Foo
{
    private IService _service;
    public Foo(IService service)
    {
    }
}

然而,现在由消费者提供服务。消费者当然也可以在构造函数中要求IService,但是当层次结构变得更深时,它似乎很烦人。在某些时候,有人需要从IoC容器请求IService - 但是当......?

我工作场所的一位前同事为UoW / Repository模式编写了一个UnitOfWork类(使用Microsoft ServiceLocator):

public static UnitOfWork
{
    public static IUnitOfWork Current
    {
        get { return ServiceLocator.Current.GetInstance<IUnitOfWork>(); }
    }

    public static void Commit()
    {
        Current.Commit();
    }

    public static void Dispose()
    {
        Current.Dispose();
    }

    public static IRepository<T> GetRepository<T>() where T : class
    {
        return ServiceLocator.Current.GetInstance<IRepository>();
    }
}

并使用Ninject连接IoC,因此对IRepository的请求将找到当前的UoW或在需要时创建一个新的(如果当前被处置)。用法变为

public class MyController
{    
    public void RunTasks()
    {
        var rep = UnitOfWork.GetRepository<Tasks>();
        var newTasks = from t in rep.GetAll()
                       where t.IsCompleted == false
                       select t;

        foreach (var task in newTasks)
        {
            // Do something
        }

        UnitOfWork.Commit();
    }
}

然而它仍然受到静态IoC(服务定位器)类的影响,但是会有更智能的解决方案吗?在这种情况下,不需要知道内部依赖性(静态类没有逻辑),并且出于测试目的,备用IoC配置可以使用模拟设置所有内容 - 并且它易于使用。

修改

我会尝试用另一个例子澄清我的困惑。假设我有一个带有MainWindow类的标准winforms应用程序。当用户单击按钮时,我需要从数据库加载一些数据,并将其传递给将处理数据的类:

public class MainWindow : Form
{
    public MainWindow()
    {
    }

    private void OnUserCalculateClick(object sender, EventArgs args)
    {
        // Get UoW to connect to DB
        // Get instance of processor
    }
}

我如何获得处理器的实例和工作单元?它可以注入表单类吗?

我想我的问题归结为:如果我在一个没有Ioc构建的类中,它可能是一个winform,一个ria服务类等 - 是否可以引用服务定位器/ IoC控制器来解析实例依赖关系,还是有一种处理这些案例的首选方式?或者我只是做错了什么......?

3 个答案:

答案 0 :(得分:1)

关于问题的第一部分:

  

消费者当然可以在构造函数中要求IService   同样,但是当层次结构成为时,它似乎很烦人   更深。

不,消费者不需要IService,需要IFoo。它不知道它将获得的IFoo依赖于IService,只有你的DI配置知道这一点。所以,不要担心,你不会最终得到你描述的依赖层次结构

  

某些人需要从IoC请求IService   容器 - 但是什么时候......?

这只会在你的composition root中发生。因此,如果它是一个MVC应用程序,你在某种程度上配置了MVC框架以在需要实例化控制器时使用你的DI配置,因此框架内部决定(来自路由)它需要MyController,并且它做了类似的事情resolver.Get<MyController>()。因此,服务位置仅在那里使用,而不是在您的控制器或其他任何地方使用。

关于问题的MyController部分:

无法真正获得与前一部分的连接,但仍然可以使用构造函数注入。没有静态类(没有注入,因此无法交换或模拟用于测试目的),没有服务位置。

[作为旁注,你甚至可以避免关于工作单元的额外代码(可能你使用的ORM有一个,你已经在IRepositories的实现中使用它)。也许你的存储库可以有一个SaveChanges方法,它会调用unitOfWork的SaveChanges - 但这是一个偏好问题,与之前的讨论无关。]

答案 1 :(得分:0)

我解决这个问题的方法是让UnitOfWorkFactory使用Create方法创建UnitOfWork

public interface IUnitOfWorkFactory
{
    IUnitOfWork Create();
}

public interface IUnitOfWork : IDisposable
{
    T GetRepository<T>();
    void Commit();
}

public class MyController
{    
    private readonly IUnitOfWorkFactory _unitOfWorkFactory;

    public MyController(IUnitOfWorkFactory unitOfWorkFactory)
    {
        _unitOfWorkFactory = unitOfWorkFactory;
    }

    public void RunTasks()
    {
        using (var unitOfWork = _unitOfWorkFactory.Create())
        {
            var rep = UnitOfWork.GetRepository<Tasks>();
            var newTasks = from t in rep.GetAll()
                           where t.IsCompleted == false
                           select t;

            foreach (var task in newTasks)
            {
                // Do something
            }               

            unitOfWork.Commit();
        }
    }
}  

拥有工厂的优势在于它允许用户(控制器)控制工作单元的创建和销毁。

这也使得单元测试更容易,因为您不需要使用IoC进行测试。我也不喜欢提供全局上下文(如UnitOfWork.Current),因为很难确定何时处置或提交UoW。

如果另一个类需要UoW的实例来向现有上下文添加额外的工作,则可以传入特定的实例。

答案 2 :(得分:0)

使用您的第一个示例,容器将同时构建IFooIService。这里有一些真实的代码来说明:

        container.RegisterType<ISubmittingService, GnipSubmittingService>(
            new DisposingTransientLifetimeManager(),
            new InjectionConstructor(
                typeof (IGnipHistoricConnection),
                typeof (IUserDataInterface),
                new EstimateVerboseLoggingService.TitleBuilder(),
                new EstimateVerboseLoggingService.FixedEndDateBuilder(),
                typeof (ISendEmailService),
                addresses,
                typeof (ILog)
                )
            );

        container.RegisterType<IEstimateService, EstimateVerboseLoggingService>(
            new DisposingTransientLifetimeManager(),
            new InjectionConstructor(
                typeof(IEstimateDataInterface),
                typeof(ISubmittingService),
                typeof(ILog)
                )
            );

...

    public EstimateVerboseLoggingService(
        IEstimateDataInterface estimateData,
        ISubmittingService submittingService,
        ILog log)
    {
        _estimateData = estimateData;
        _submittingService = submittingService;
        _log = log;
    }

...

    public GnipSubmittingService(
        IGnipHistoricConnection gnip,
        IUserDataInterface userDb,
        IBuilder<string, int> titleBuilder,
        IBuilder<DateTime, DateTime> endDateBuilder,
        ISendEmailService emailService,
        IEnumerable<MailAddress> errorEmailRecipients,
        ILog log)
    {
        _gnip = gnip;
        _userDb = userDb;
        _titleBuilder = titleBuilder;
        _endDateBuilder = endDateBuilder;
        _emailService = emailService;
        _errorEmailRecipients = errorEmailRecipients;
        _log = log;
    }

在此代码中,EstimateVerboseLoggingService消费ISubmitingService。这两种实现都在容器中指定。