【问题标题】:Static factories - good practice?静态工厂——好的做法?
【发布时间】:2014-08-04 14:43:08
【问题描述】:

我有一个静态日志管理器类,它应该基于参数返回所需记录器的实例。

public static class LogManager {

    private static ILoggerFactory Factory { ... }

    public static ILogger GetLogger(string name) {
        return Factory.Create(name);
    }

}

由于必须设置 ILoggerFactory 的具体实现(初始化),我想知道我是否应该只保留对实现类型的引用并在每次请求工厂时返回一个新实例 - 或者是否可以保留实现实例的静态引用。

版本 1

private static Type _factoryType;

public static void SetFactory<TFactory>()
    where TFactory : ILoggerFactory, new()
{
    _factoryType = typeof(TFactory);
}

private static Factory {
    get { return (ILoggerFactory)Activator.CreateInstance(_factoryType);
}

public static ILogger GetLogger(string name) {
    return Factory.Create(name);
}

第 2 版

private static ILoggerFactory _loggerFactory;

public static void SetFactory<TFactory>()
    where TFactory : ILoggerFactory, new()
{
    _loggerFactory = (ILoggerFactory)Activator.CreateInstance<TFactory();
}

public static ILogger GetLogger(string name) {
    return _loggerFactory.Create(name);
}

【问题讨论】:

    标签: c# design-patterns logging static factory-pattern


    【解决方案1】:

    可以说,主要区别似乎在于延迟加载:v1 将在调用 GetLogger 时创建记录器类型,而 v2 将在 SetFactory 期间创建记录器。其他方面没有太大区别。可以将引用保留为对记录器类型或工厂本身的私有静态字段。

    但是,如果这是生产代码,我会完全摆脱这个日志管理器和工厂。相反,我会直接使用日志框架,例如 nlog 或 log4net。这简化了代码并使其更易于维护。在这种情况下构建抽象是过度设计的。

    【讨论】:

    • 啊,旧的“抽象日志框架”讨论。在我们的大多数应用程序中,我们公司多年来直接使用 log4net。但是,对于某些我们需要打开不同的“框架”,例如 System.Diagnostics.TraceSource 和 EntLib 用于某些目的。我们现在甚至在讨论切换到 NLog。我们得出的结论是,如果每个开发人员在每个应用程序中都以相同的方式记录会更容易,但如果应用程序之间的需求发生变化,我们仍然可以切换到不同的框架。那么 - 为什么不抽象出要删除什么框架的决定呢?
    猜你喜欢
    • 1970-01-01
    • 2012-09-07
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多