C# 复杂共享/静态成员的最佳实践

我接管了一个ASP.NET应用程序，并在该应用程序的几个类中发现了这一点。之前的程序员定义了几个共享/静态变量，这些变量在整个应用程序中充当“复杂枚举”。作为一个相当新的程序员，它看起来不像是最佳实践

以下是一个例子：

Public Shared SecureCommentsWrite As New Task("Secure Comments Write")
Public Shared SecureCommentsRead As New Task("Secure Comments Read")
Public Shared EditEmergencyContact As New Task("Edit Emergency Contact")
Public Shared DisplayPersonalReferences As New Task("Display Personal References")
Public Shared EditPersonalReferences As New Task("Edit Personal References")

构造函数获取描述，然后使用存储过程（数据库是SQL Server）从数据库加载ID密钥。这似乎是个好主意，因为我们将此应用程序部署到多个数据库，并希望确保加载该数据库中的ID密钥，以防其发生更改。然而，由于应用程序中有成百上千个这样的应用程序，第一次加载需要一段时间

---

这被认为是最佳实践吗？如果不是，在这种情况下，什么是最佳实践？

对于我来说，这是一种可怕的实践，如果您告诉我，对于上面的每一行和任务构造函数，都会调用一个单独的存储过程（即使是相同的存储过程）

这种情况下的最佳实践是重构，对该存储过程进行一次调用，并对其进行修改以返回所有ID和名称，然后使用一个小TaskManager或TaskLoader（无论什么）类映射存储结果并创建所有这些元素，而无需进一步涉及数据库

在这些情况下，请注意SqlDataReader可能比DataSet更好，因为您只需要对数据进行仅前向、只读的快速访问

---

这就是我这边的一切；-）

这里可能需要一个工厂类（

TaskFactory

？）

它应该加载（一次）一个数据表或数据集，该数据表或数据集表示整个

任务列表

项。这可以由构造函数完成，或者在执行实例的第一个请求时[延迟地]完成

---

工厂的

CreateInstance（）

方法不应该每次都点击数据库，而应该查阅预加载的数据以了解它需要什么。

在对象构造函数中运行数据库查询/存储过程或任何其他可能耗时的操作不是一个好做法。 如果在任务对象的初始化过程中出现问题，由于它被声明为静态/共享成员，它可能会抛出TypeInitializationException，并且您的应用程序将变得不可用

---

我会将这些成员视为某种应用程序配置。在应用程序启动期间执行一个存储过程，该过程将一次性（而不是逐个）带来所有数据，并创建配置对象

拥有表示常量值的静态字段列表本身并没有什么错；正如您所指出的，它本质上与枚举相同，并且Microsoft已经在他们自己的一些库中完成了这项工作

也就是说，如果初始化这些字段会导致明显的速度减慢（而且因为它们都在访问一个数据库，这并不奇怪），那么可以使用一些技术来改进加载时间。一个明显的解决方案是采用延迟加载——换句话说，在绝对必要之前不要点击数据库！这实质上是在程序的整个生命周期中分摊了访问数据库以初始化这些字段的成本，为您提供了更快的启动速度，以换取其他地方稍慢的性能

当然，如果你不得不一次延迟加载100或1000个，那也可能不是理想的解决方案；在这种情况下，您只是将大量延迟转移，而不是将其分解

另一个想法是提高负责检索这些ID的SQL的效率。您可以编写一个

Initialize（）

方法来执行一个查询，一次提取出所有需要的ID，而不是在100个不同的查询中执行。这几乎肯定会更快