复杂共享/静态成员的最佳实践答案

【问题标题】：Best practice for complex shared/static members复杂共享/静态成员的最佳实践
【发布时间】：2011-09-07 18:53:08
【问题描述】：

我接管了一个 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 密钥，以防它发生变化。但是，由于应用程序中实际上有数百个，因此第一次加载需要一段时间。

这是否被认为是最佳做法，如果不是，对于这种情况，什么被认为是最佳做法？

【问题讨论】：

标签： c# .net asp.net vb.net static

【解决方案1】：

对我来说，这是一种可怕的做法，如果你告诉我上面的每一行和 Task 构造函数都会调用一个单独的存储过程（即使存储相同）。

在这种情况下的最佳实践是重构，对该存储过程进行一次调用并对其进行修改以返回所有 ID 和名称，然后使用一个小的 TaskManager 或 TaskLoader（随便）类来映射存储的结果并创建所有这些没有进一步的数据库参与的元素。

在这些情况下，请注意 SqlDataReader 可能比 DataSet 更好，因为您只需要转发、只读快速访问数据。

这就是我这边的全部;-)

【讨论】：

【解决方案2】：

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

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

当然，如果您必须一次延迟加载 100 或 1000 个，那也可能不是理想的解决方案；在这种情况下，你只是转移了巨大的延迟，而不是打破它。

另一个想法是提高负责检索这些 ID 的 SQL 的效率。您可能会编写一个Initialize() 方法来执行单个查询以一次提取您需要的所有 ID，而不是在 100 个不同的查询中执行此操作。这几乎肯定会更快。

【讨论】：

【解决方案3】：

你可能想要一个工厂类 (TaskFactory?)。

它应该加载（一次）代表Task 项目的整个列表的DataTable 或DataSet。这可以由构造函数完成，或者在执行对实例的第一个请求时[懒惰地]。

工厂的CreateInstance() 方法应该查询预加载的数据，而不是每次都访问数据库。

【讨论】：

【解决方案4】：

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

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

【讨论】：