1

我已阅读有关何时使用静态类以及何时建议使用实例类的帖子。但是，我的印象是我下面的示例介于两者之间：

  • 不需要类实例，存储的状态在 AppDomain 内的成员之间共享。
  • 应该可以从 AppDomain 中的不同类实例访问状态。
  • 不需要抽象或覆盖。

所以，我的问题是：我应该继续使用它作为静态还是使用单例概念更好？

public static class SubscriptionManager
{
    private static Dictionary<string, string> Repository { get; set; }

    static SubscriptionManager()
    {
        Repository = new Dictionary<string, string>();
    }

    public static void Subscribe(string key, string value)
    {
        if (Repository.ContainsKey(key))
            Repository[key] = value;
        else
            Repository.Add(key, value);
    }

    public static void Unsubscribe(string key, string value)
    {
        if (Repository.ContainsKey(key))
            Repository.Remove(key);
    }

    public static string GetSubscription(string key)
    {
        if (Repository.ContainsKey(key))
            return Repository[key];
        else
            return "";
    }
}
4

2 回答 2

0

请记住，大型静态类会占用大量内存，因此在不必要时避免使用它们。在这种情况下，我建议您使用静态类。这种方式比较好。

于 2013-09-01T03:47:56.580 回答
0

您的示例提供了类似存储库的模式的显式实现，如果它是可扩展的，最终可能会证明它更有价值。如果你将它作为一个静态类来实现，那么你现在就决定这是不可能的。

另一个可能有价值的实现的示例可能是使用 .NET 4 ConcurrencyDictionary<TKey, TValue>，因此代码可以在更大容量的并发场景中使用，因为Dictionary该类不是线程安全的。

您的建议是非常 YAGNI，这对于具有某种计划的大型项目的迭代很有用，但除非您知道未来会发生什么，否则为什么要限制已经编写的代码的潜力？

我可能会从您的类生成一个接口来表示其基本框架（将实现与合同分开），并利用 IoC 容器让您的类的用户决定为他们的场景使用什么实现。

当然，这仅在您的项目相当小或关心项目之间共享代码的情况下才重要。祝你好运！

于 2013-09-01T04:54:28.193 回答