枚举类模式是否与DI不兼容?

时间:2013-11-18 10:59:28

标签: c# .net dependency-injection ioc-container simple-injector

在进入DI之前,我非常喜欢使用所谓的枚举类(或者我脑子里的强枚举),其中枚举被转换为类,但设置为以类似于枚举的方式使用。这使得真正属于特定枚举的逻辑能够被封装在正确的位置,并防止代码库中的大量混乱。

这里有一个例子http://lostechies.com/jimmybogard/2008/08/12/enumeration-classes/

一旦你将DI引入等式,虽然它因为依赖于静态变量而成为问题。

有没有办法继续支持这种模式并使用DI?

编辑: 如果我想在EmployeeType中注入一些新东西,这是一个有问题的类型示例。由于静态变量,我无法使用容器。

public class EmployeeType : Enumeration
{
    public static readonly EmployeeType Manager 
        = new ManagerType (0, "Manager");
    public static readonly EmployeeType Servant 
        = new EmployeeType(1, "Servant");
    public static readonly EmployeeType AssistantToTheRegionalManager 
        = new EmployeeType(2, "Assistant to the Regional Manager");

    private EmployeeType() { }
    private EmployeeType(int value, string displayName) : base(value, displayName) { }
}

public class ManagerType : EmployeeType
{
}

3 个答案:

答案 0 :(得分:3)

我认为你可以在这里使用Strategy pattern。您可以保留枚举类型或使用任何类型,而不是帮助您识别策略(我将在我的示例中使用字符串)。然后为每个值实施策略。

interface IEmployeeHandler
{
    string EmployeeType { get; }
    void Handle(Employee employee);
}

class ManagerHandler : IEmployeeHandler
{
    public ManagerHandler()
    {
        EmployeeType = "Manager";
    }

    public string EmployeeType { get; private set; }
    public void Handle(Employee employee) { }
}

class ServantHandler : IEmployeeHandler
{
    public ServantHandler()
    {
        EmployeeType = "Servant";
    }

    public string EmployeeType { get; private set; }
    public void Handle(Employee employee) { }
}

由于DI容器可以注入接口的多个实现,因此您可以编写如下的策略提供程序类:

class EmployeeStrategyProvider
{
    private readonly IEmployeeHandler[] _employeeHandlers;

    public EmployeeStrategyProvider(IEmployeeHandler[] employeeHandlers)
    {
        _employeeHandlers = employeeHandlers;
    }

    public IEmployeeHandler GetStrategy(string employeeType)
    {
        return _employeeHandlers.FirstOrDefault(item => item.EmployeeType == employeeType);
    }
}

您可以根据员工类型使用此类来获取正确的策略。这就是我用DI容器实现Strategy模式的方法。它可以使用一些改进,我 很高兴听到一些建议。

答案 1 :(得分:2)

我一直在使用这种模式一段时间,但从未考虑过需要注入服务。但是,它应该是可能的吗?

一种解决方案是延迟创建依赖于服务实例的任何枚举,直到需要它们为止 - 其他所有内容仍然看起来像一个常规的静态类型。

以下是EmployeeType类,其中添加了Manager的延迟实例化,该实例取决于IBonusService

public class EmployeeType : Enumeration
{
    public static Func<IBonusService> BonusService { private get; set; }

    private static EmployeeType _manager = null;
    public static EmployeeType Manager { 
        get 
        {
            if (_manager == null) _manager = new ManagerType(BonusService());
            return _manager;
        } }

    public static readonly EmployeeType Servant
        = new EmployeeType(1, "Servant");
    public static readonly EmployeeType AssistantToTheRegionalManager
        = new EmployeeType(2, "Assistant to the Regional Manager");
    private EmployeeType(int value, string displayName) :
       base(value, displayName) { }

    public virtual decimal BonusSize { get { return 0; } }

    private class ManagerType : EmployeeType
    {
        private readonly IBonusService service;
        public ManagerType(IBonusService service) : base(0, "Manager")
        {
            this.service = service;
        }

        public override decimal BonusSize {
            get { return this.service.currentManagerBonus; } }
    }
}

您在组合根目录中配置依赖项:

[Test]
public void EmployeeType_Manager_HasBonusService()
{
    Container container = new Container();
    container.Register<IBonusService, BonusServiceStub>();
    EmployeeType.BonusService = () => container.GetInstance<IBonusService>();

    BonusServiceStub.constructed = false;
    container.Verify();
    //Verify has ensured the container can create instances of IBonusService
    Assert.That(BonusServiceStub.constructed, Is.True);

    EmployeeType manager = EmployeeType.Manager;
    Assert.That(manager.BonusSize == 999m);
}


public class BonusServiceStub : IBonusService
{
    public static bool constructed = false;

    public BonusServiceStub() { constructed = true; }

    public decimal currentManagerBonus { get { return 999m; } }
}

特别注入Func<IBonusService>而不是IBonusService的原因是服务的生命周期范围(以及装饰等)在组合根中进行管理,并且保持独立于消费者。

答案 2 :(得分:0)

你可以为你的枚举类使用Singleton。