工厂模式在依赖注入

我有一个类，看起来像这样：工厂模式在依赖注入

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是一个回购协议，负责一些数据存储通信得到一个IThing的标识。而IThingFactory是一个简单的工厂，返回给定字符串属性的new IThing。

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

谢谢

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

来源

2016-05-13 Rhs

你能形容'IThing'吗？有多少类实现它？这是一个简单的财产包？它是否包含您可能想要改变的行为？ –

'IThing'仅由1类实现，但可以通过在未来其他类来实现。这是一个单一的财产包。 – Rhs

看看[这篇文章newables和注射剂（http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/）。 –

如果我思的是，并不需要比输出多从数据库中的类（所以如果需要从DI容器没有），你不想要嘲笑它进行测试，恕我直言，你可以通过调用创建类构造函数。

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

对于NInject，有一个factory extension，这使得创建工厂非常容易 - 您只需创建接口并在运行时创建相应的实现。

来源

2016-05-13 06:50:08 JanDotNet

依赖注入是实现层间松散耦合的技术，不完全是我将其描述为设计模式的技术。

混合设计模式或使用多种技术作为一般事情来说明没有什么错，除非您在不需要的地方引入复杂性。

所以我的建议是通过质疑您的需求和理解设计模式的使用来处理事情，然后您将能够认识到需要使用某种模式来使您的代码可维护，可扩展或任何技术要求正在努力实现。

的问题，我都会问自己：

什么是我试图解决这个问题？

这个逻辑会如何扩展？什么是移动部分，核心要求是什么？

哪种设计模式解决了这种问题？

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

来源

2016-05-13 06:20:52

工厂模式在依赖注入

回答

相关问题