管理工厂类的基类

Question

我有一个 StaffFactory 用于通过各种方式获取 Staff 对象，但我也有一些设置方法来确定要使用哪个数据源。

class StaffFactory
{
    private const string DefaultDbSourceName = "Production";
    private string dbSourceName;
    #region Factory Management
    private static Dictionary<string, StaffFactory> staffFactories = new Dictionary<string,StaffFactory>();
    public static StaffFactory GetInstance()
    {
        return GetInstance(DefaultDbSourceName);
    }
    public static StaffFactory GetInstance(string dbSourceName)
    {
        if (!staffFactories.ContainsKey(dbSourceName))
        {
            staffFactories.Add(dbSourceName, new StaffFactory(dbSourceName));
        }
        return staffFactories[dbSourceName];
    }
    private StaffFactory(string dbSourceName)
    {
        this.dbSourceName = dbSourceName;
    }
    #endregion Factory Management
    #region Factory Methods
    public Staff ById(int id) { ... }
    public IList<Staff> ByName(string name) { ... }
    ...
    #endregion Factory Methods
}

当我要创建下一个工厂时，我意识到无论工厂是什么类型，所有这些管理逻辑都将保持不变。所以我想我创建一些包含该逻辑的基本 Factory 或 Factory 类，然后使用 class StaffFactory : Factory声明上述内容{ ... } 之类的，但我对如何解决这个问题完全空白。是否使用泛型等来实现它。

任何人都可以指出我正确的方向吗？

Answer 1

在引入新的抽象层之前，请确保收益大于成本。在您的情况下，这些将包括：

设计和实现抽象的成本

StaffFactory 比通用 Factory更容易设计、实现和测试。班级。

了解工厂的成本抽象

每次有人阅读代码时，他们可能都需要思考抽象。通用抽象比非通用抽象更难理解。

未来进行更改的成本

假设您有 Factory和 Factory，将来您会发现您需要为两者采用不同的缓存策略。也许工厂<产品>如果缓存大小超过某个阈值，则应丢弃缓存的对象。

您打算概括 Factory<> 吗？类支持不同的模式？这是可以做到的，但它比单独修改 StaffFactory 和 ProductFactory 类要复杂得多。

总结

因此，不要仅仅为了抽象而引入抽象。并且，绝对不要将 StaffFactory 概括为通用 Factory。如果工厂<员工>将是您拥有的唯一通用实例化。

从上面的代码来看，您的 Factory似乎是类基本上是一个 Dictionary。如果是这样的话，那么引入额外的泛型 Factory 类不会给您带来太多好处，只会添​​加不必要的抽象层。

Answer 2

据我了解，您要实现的是存储库模式。请参阅C# 存储库模式教程的答案。