依赖注入中的工厂模式

时间:2016-05-13 05:08:12

标签: c# dependency-injection

我有一个看起来像这样的课程:

public class SomeRepo : ISomeRepo
{
    private IThingFactory _thingFactory;

    public class SomeRepo (IThingFactory thingFactory)
    {
        _thingFactory = thingFactory;
    }

    public IThing GetThingFromDatabase(int id)
    {

        string thingName = /* some call that gets back some primitives */
        IThing returnVal = _thingFactory.createThing(thingName);

        return returnVal;
    }
}

简而言之,SomeRepo是一个repo,负责与某个数据存储区通信以获取Id IThingIThingFactory是一个简单的工厂,在给定字符串属性的情况下返回new IThing

如果我使用的是依赖注入容器,我还应该依赖IThingFactory吗?为了方便起见,似乎我正在混合两种设计模式。有没有更优雅的方法来构建IThing而不需要工厂,或者我有一个好的模式可以遵循?

由于

编辑:我使用的DI容器是Ninject。

2 个答案:

答案 0 :(得分:1)

依赖注入是实现层之间松散耦合的技术,而不是我所描述的设计模式。

混合设计模式或使用多种技术作为一般情况说明没有任何问题,除非你在不需要的地方引入复杂性。

所以我的建议是你通过质疑你的需求和理解设计模式的使用来处理事情,然后你就能够认识到需要使用某种模式来使你的代码可维护,可扩展或者你需要什么技术要求试图实现。

我会问自己的问题:

我想解决的问题是什么?

这种逻辑的可扩展性如何?什么是移动部件以及核心要求是什么?

哪种设计模式可以解决这类问题?

您还需要权衡代码中引入的复杂性和使用某些设计模式所消耗的时间以及在短期和长期使用它的好处吗?

答案 1 :(得分:1)

如果IThink是一个不需要多于数据库输出的类(所以如果它不需要来自DI容器)并且你不想模拟它进行测试,恕我直言你可以通过调用构造函数来创建类

否则工厂模式是我眼中的正确选择。

对于NInject,有一个factory extension可以很容易地创建工厂 - 您只需创建接口,扩展就可以在运行时创建相应的实现。