【问题标题】:Static Provider Dictionary Design静态提供者字典设计
【发布时间】:2012-02-22 17:32:54
【问题描述】:

我正在重新考虑我们现在正在使用的当前 WCF 服务。我们做了很多将 XML 加载到各种数据库的工作。在某些情况下,我们可以将其存储为 XML 数据,而在其他情况下,我们需要将其存储为行集。

所以我正在重新设计这项服务以接受不同的提供商。我的第一个想法是经典的抽象工厂,但现在我有疑问了。本质上,服务类有一个操作契约方法,Load。但对我来说,每次调用 Load 时都新建提供程序实例似乎很愚蠢。

目前:

// Obviously incomplete example:
public class XmlLoaderService : IXmlLoaderService
{
    readonly IXmlLoaderFactory _xmlLoaderFactory;
    readonly IXmlLoader _xmlLoader;

    public XmlLoaderService()
    {
        _xmlLoader = _xmlLoaderFactory(ProviderConfiguration configuration);
    }

    public void Load(Request request)
    {
        _xmlLoader.Load(request);
    }
}

我正在考虑改成:

public class XmlLoaderService : IXmlLoaderService
{
    static readonly IDictionary<int, IXmlLoader> _providerDictionary;

    static public XmlLoaderService()
    {
        _providerDictionary = PopulateDictionaryFromConfig();
    }

    public void Load(Request request)
    {
        // Request will always supply an int that identifies the
        // request type, can be used as key in provider dictionary

        var xmlLoader = _providerDictionary[request.RequestType];
        xmlLoader.Load(request);
    }
}

这是一个好方法吗?我喜欢缓存提供程序的想法,对我来说似乎更有效......虽然,我有时会忽略显而易见的事情。让我知道你的想法!

【问题讨论】:

    标签: c# .net wcf design-patterns abstract-factory


    【解决方案1】:

    为什么不能同时使用?将您的依赖项传递到 Load 方法中,如果该类型已被缓存,则使用缓存的实例。

    public void Load(Request request)
    {
        // Request will always supply an int that identifies the
        // request type, can be used as key in provider dictionary
    
        IXmlLoader xmlLoader;
        if(_providerDictionary.ContainsKey(request.RequestType))
        {
            xmlLoader = _providerDictionary[request.RequestType];
        }
        else 
        {
            xmlLoader =  //acquire from factory
            _providerDictionary.Add(request.RequestType, xmlLoader);
        }
        xmlLoader.Load(request);
    }
    

    【讨论】:

    • 谢谢,我假设您认为在这种情况下缓存提供程序是一个可行的选择,所以我会接受提供的最佳(尽管是唯一)答案!谢谢!
    猜你喜欢
    • 2012-12-09
    • 2011-06-30
    • 2011-03-04
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-03-09
    • 2020-10-15
    相关资源
    最近更新 更多