这是一个与我刚刚提出的以下问题有关的半相关问题：
Utility classes.. Good or Bad?
在确定一个类作为存储在XML文件中的Url解析规则的缓存之后，我认为单例可以解决我的问题，但是引入了全局状态（尽管它只是向一个方向传播XML - ＆gt;解析器）和静态依赖。
让我考虑单例的设计考虑因素是:(请注意，这是一个使用模块来捕获和解析使用相同解析器的所有请求的Web应用程序）
在这种情况下单身是否有效？你会如何解决这个问题？
答案 0 :(得分：5)
我会考虑将规则存储在HttpContext.Cache中，该规则可供所有会话使用。您可以在卸载缓存时重建缓存（由于缺少使用）。
答案 1 :(得分：5)
不需要具有所有相关缺点的单身人士（customary anti-singleton link）。
我喜欢将其存储在HttpContext.Cache中的建议。一些类似的替代方案：
将其存储在HttpApplication.Application
将属性添加到应用程序类以存储它，然后在相关的HttpModule中存储对应用程序的类级别引用。
答案 2 :(得分：1)
你的解决方案听起来不错。特别是如果消费代码没有修改数据，那么使用单例或静态类听起来应该不是问题。我不确定是否将其标记为“单身”是必要的，尽管我认为这是它的表现。
您可以使用本身“缓存”的静态类，因为它位于ASPNET工作进程内存中，或者您可以将其显式缓存到Web缓存中。如果您执行后者，您可以通过向缓存条目添加文件依赖项来获益，因此任何文件更改都会强制从缓存重新加载。
答案 3 :(得分：1)
我不会使用单例，因为这会使应用程序更难测试。大多数IoC容器可以帮助您使用“单（吨）”实例替换此模式，该实例在使用单例的所有类之间共享。
答案 4 :(得分：0)
很容易让IoC容器为你提供单例，我认为很难证明使用传统的Singleton模式是合理的。
答案 5 :(得分：0)
只要您需要多个对象实例，单身人士就可以被证明是合理的。术语“单例”有点误导，因为通常使用相同的软件设计模式来控制类的多个实例。
您可以使用静态类，或在静态引用上挂起单例实例，或将其存储在其中一个asp.net Web集合中。单身人士可以参与未来的继承等等......对于静态类与单身人士模式，我不会参与该论证，因为它已经thoroughly addressed online, even on StackOverflow
答案 6 :(得分：0)
我很快就会说不，只是试着将它绑定到它的'范围'。如果它是应用程序范围，那么尝试将其绑定到应用程序。如果它是会话绑定的，则将其放入会话等。如果您想要在同一容器中运行2个应用程序，这将有所帮助。我没有使用ASP.NET的经验，但似乎有一个'HttpApplicationState'。你能用吗？