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

我接管了一个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")

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

这被认为是最好的做法，如果没有，什么被认为是这样的情况最好的做法？

来源

2011-09-07 Spencer Schneidenbach

拥有代表常量值的静态字段列表并不存在固有的错误;正如您所指出的那样，它基本上与枚举相同，而且微软自己在一些自己的库中完成了它。也就是说，如果初始化这些字段导致明显的减速（并且因为它们每次都触及数据库，这并不是真正的惊喜），可以使用一些技巧来提高加载时间。一个显而易见的解决方案是采用延迟加载 - 换句话说，直到你绝对必须的时候才打到数据库！这基本上分摊了在数据库的整个生命周期中触发数据库以初始化这些字段的成本，从而为您提供更快的启动速度，以换取其他地方稍微较慢的性能。

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

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

来源

2011-09-07 19:06:00

对我来说这是一个可怕的做法，如果你告诉我，每个上面和任务建构一个分开的存储过程，这些行被称为（即使相同的存储）。

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

在这些情况下

注意到一个SqlDataReader很可能会比一个DataSet更好，因为你只需要只进，读取到的数据只有快速访问。

，现在一切都从我身边;-)

来源

2011-09-07 19:04:50

你可能想在这里一个工厂类（TaskFactory？）。

应该加载（一次）表示的Task项的整个列表的DataTable或数据集。这可以通过构造函数来完成，或者在执行第一个实例请求时[懒洋洋地]完成。

每次而不是击中分贝，工厂的CreateInstance()方法则应该咨询它所需要的预加载数据。

来源

2011-09-07 19:05:34

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

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

来源

2011-09-07 19:05:35 Vasea

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

回答

相关问题