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

本文关键字：最佳 共享 复杂 静态成员 | 更新日期: 2023-09-27 18:07:49

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

这被认为是最佳实践吗?如果不是，对于这种情况，什么被认为是最佳实践?

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

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

在这种情况下的最佳实践是重构，对该存储过程进行一次调用并修改它以返回所有id和名称，然后使用一个小TaskManager或TaskLoader(无论什么)类来映射存储的结果并创建所有这些元素，而不需要进一步的数据库参与。

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

我这边就讲到这里;-)

拥有代表常量值的静态字段列表本身并没有什么错;正如你所指出的，它本质上和枚举是一样的，微软已经在他们自己的一些库中实现了这一点。

也就是说，如果初始化这些字段会导致明显的减速(因为它们每个都要访问一个数据库，这并不奇怪)，那么您可以使用一些技术来缩短加载时间。一个显而易见的解决方案是采用延迟加载——换句话说，除非绝对必要，否则不要访问数据库!这基本上在程序的整个生命周期中分摊了访问数据库初始化这些字段的成本，从而使您的启动速度更快，而其他地方的性能则有所降低。

当然，如果您必须一次惰性加载100或1000个这样的对象，这可能也不是理想的解决方案;在这种情况下，你只是移动了大量的延迟，而不是将其分解。

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

您可能需要一个工厂类(TaskFactory ?)。

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

工厂的CreateInstance()方法不应该每次都访问db，而应该咨询预加载的数据以获取所需的内容。

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

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

相关文章：