用于管理工厂类的基类

Question

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

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
}

当我要创建我的下一个工厂时，我意识到无论工厂的类型是什么，所有这些管理逻辑都将保持不变。所以我在想，我应该创建一些包含这种逻辑的基工厂或工厂类，然后用class StaffFactory : Factory<Staff> { ... }或其他东西声明上面的内容，但我对如何实现这一点完全是一片空白。是否使用泛型实现它，等等。

有谁能给我指个方向吗？

Answer 1

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

设计和实现抽象的成本

StaffFactory比泛型工厂类更容易设计、实现和测试。

了解工厂抽象的成本

每当有人阅读代码时，他们可能需要将他们的头脑围绕在抽象上。泛型抽象比非泛型抽象更难理解。

在未来的中进行更改的成本

假设您有Factory和Factory，将来您会发现需要对这两个使用不同的缓存策略。如果缓存大小超过某个阈值，工厂可能会丢弃缓存的对象。

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

摘要

所以，不要仅仅为了抽象而引入抽象。而且，如果工厂将是您将拥有的唯一泛型实例化，则绝对不要将StaffFactory泛化为泛型工厂。

从上面的代码可以看出，您的工厂类基本上是一个Dictionary。如果是这样，那么引入额外的generic Factory类不会给你带来太多好处，只会增加一个不必要的抽象层。

Answer 2

据我所知，您将要实现的是一个Repository模式。请参阅Repository pattern tutorial in C#的答案。