C# 适合继承的工厂或DI

我有不同种类的报价，像船报价，摩托车报价，汽车报价，这些都来自报价类。当客户想要获得报价时，我只需返回报价。 我可以通过两种方式实施：

工厂：

public class QuoteFactory{
     public Quote GetQuote(string QuoteType )
     {
      if(quoteType = "car")
         {
           return new CarQuote()
        }
     }

带弹簧芯的DI

将所有报价类型添加到上下文中，然后让客户机决定需要哪种类型。

---

提前感谢。

如果您只需要一个报价，那么这种方法有什么意义。调用方法知道它想要什么类型的引号——它必须作为参数传入。如果您真的想将quote的创建抽象为一个可注入类（例如单元测试），为什么不创建一个泛型方法，例如：

public class QuoteFactory : IQuoteFactory
{
    public TQuote CreateQuote<TQuote>()
        where TQuote : new() // or Quote if specific attributes requied to be set by factory
    {
        return new TQuote();
    }
}

公共类QuoteFactory:IQuoteFactory
{
公共TQuote CreateQuote（）
其中TQuote:new（）//如果工厂需要设置特定属性，则使用引号
{
返回新的TQuote（）；
}
}

不确定您的问题，但这是使用DI的重构工厂：

public class QuoteFactory : IQuoteFactory{
    public QuoteFactory(Quote boatQ, Quote motorQ, Quote carQ){
        // parameter assignment
    }
    Quote boatQ;
    Quote motorQ;
    Quote carQ;

    public Quote Create(string quote){
        if(quote == "car") return carQ;
        //further condition
    }
}

---

使用这种设计，您可以依赖DI容器来处理构造函数注入。此外，您可以通过注入

IDictionary

来替代此设计。

您应该使用满足您需求的设计，并且您只列出了一个您认为两种方法都可以满足的设计。您还没有为DI案例提供任何代码，我不确定如何使用DI实现这一点。如果它们都满足了你的需求，抛硬币，如果你发现你的设计妨碍了可测试性或其他什么，那么稍后再重构。你只是在吹嘘还是有问题？@itsme86我认为这是“我应该使用工厂还是DI？”仍然不是一个很好的问题，因为两者都是一样的，而且选择是任意的，没有其他要求，或者只有其中一个会起作用，而且选择是显而易见的。（或者OP希望我们给他一个非功能性设计约束的例子，在这种情况下，我的魔术八球说前景不太好，因为现在对建筑宇航员的独白来说不太好。）ITSME，只是认为我是一个新的学习学习设计模式的人：在这种情况下，我可以推荐一本书吗？此外，设计模式在解决问题时并不是零重叠的。目前的群体思维是，SO不是一个教学网站，“做X的最佳方式是什么？”缺乏任何其他约束的问题表现不佳。特别是因为这意味着你的问题没有上下文，而“现实世界”的解决方案实际上可能是几个工厂，每个工厂都在需要的地方注入。（因此，销售汽车的模块可能会得到一个

CarQuoteFactory

等）或者它可能不会，没有上下文就很难判断。感谢VegDork，我以前也在某个地方读过关于TQuote风格的文章，我想这可能是我想要的。当然，这与抽象报价创建完全相反（这是工厂应该做的），因为它所能做的就是创建引号的不同子类型，完全相同。对于引号工厂来说，它作为基类更有用，子类然后初始化类型特定的属性。