Home/ Questions/Q 6534215
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T10:13:26+00:00

I took over an ASP.NET application and have found this throughout several classes in

  • 0

I took over an ASP.NET application and have found this throughout several classes in the application. The programmers before defined several shared/static variables that act as “complex enums” throughout the application. As a fairly new programmer, it doesn’t look like best practice.

Here is an example:

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")

The constructor takes the description, then loads the ID key from the database using a stored procedure (the database is SQL Server.) This seems like a good idea since we deploy this application to multiple databases and want to ensure that we load the ID key that’s in that database in case it changes. However, since there are literally hundreds of these in the application, the first load takes a while.

Is this considered best practice, and if not, what is considered to be best practice for a situation like this?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    There’s nothing inherently wrong with having lists of static fields that represent constant values; it is, as you pointed out, essentially the same as an enumeration, and Microsoft has done it themselves in some of their own libraries.

    That said, if initializing these fields is causing a noticeable slowdown (and since they’re each hitting a database, that’s no real surprise), there are a few techniques you could use to improve loading times. An obvious solution is to employ lazy loading–in other words, don’t hit the database until you absolutely have to! This essentially amortizes the cost of hitting the database to initialize these fields over the entire life of the program, giving you a much faster startup in exchange for somewhat slower performance elsewhere.

    Of course, if you have to lazy load 100 or 1000 of these at once, that may not be the ideal solution, either; in that case you’ve just moved the massive delay around, rather than breaking it up.

    Another idea would be to improve the efficiency of the SQL responsible for retrieving these IDs. You might write a single Initialize() method that performs a single query to pull out all of the IDs you need at once, rather than doing it in 100 different queries. That will almost certainly be faster.

    • 0