One of the major benefits of using a data access layer (DAL) is that a developer can hide a lot of dirty code that would otherwise clutter up business logic that needs to be easily accessible and readable. You can do a lot with a DAL, including handling errors and what to return to the application when nothing returns from the data source. Sometimes this is fine for one developer, but other times another developer might want some more control over calling that DAL.

For example, let’s say that in your DAL, you’re making a call to your database to retrieve a set of records. At the DAL level, there is no way to know what these records are going to be used for. They might be loaded into a data grid and be modified, in which case there would be a need to reload that data and rebind to it. They also might just be values that are being loaded as lookup values, in which case they can probably just be loaded once, with no need to hit the database a second time.

In .Net, an easy way to store the data once it’s retrieved from the database is to put it into the ViewState. This way, you don’t have to worry about reloading the data at every PostBack. Here is a simple example:

 Note: The record class type must be serializeable to be able to be loaded into the ViewState.

The obvious flaw in this code is that it will be loaded every time the page is loaded or a PostBack is performed. A few options could solve this:

The records will only be loaded when the page is first loaded and then persist throughout the rest of the time the user is on this page.

When the page is loaded the first time, ViewState(“record_list”) will be Nothing, so the code inside the If statement will execute to load the data into the ViewState. Subsequent PostBacks will cause the If statement to be False and not load the data again.

The problem now is that we are directly using the ViewState, so the code is a bit fragile (what happens if we accidentally type “records_list”?), and we aren’t easily able to perform many actions on our data, such as filtering or sorting. We need something to “wrap” our data with.

Now, the data is able to be persisted in the ViewState, but also allow us to easily iterate through it, or modify it. But, what happens when we want to reference record_list later on? What if we are doing something with the data on PreRender, so another developer moves the reference to the repository to there, but ignores the fact that we’re using our list as a DataSource in a NeedsDataSource event?

Having to check if the data is loaded at every step of the way is going to clutter our code up quickly! If we’re only setting the value of our property when we need to get the data, why not let the property take care of that step as well? Just to make sure that we don’t screw it up somewhere else along the way, we can make it a ReadOnly property and encapsulate all of the “getting” logic right inside.

And now the main part of our simple program, just got much more simple:

The methods suddenly don’t have to worry about when or where the data is coming from. If the data is there in the ViewState when record_list is referenced, great! If not, grab it and move on.

Now everything is great if you only care about loading the data once for the page, but what about if you need to modify a record in the database and then get that data again?

Like most things with software development, there’s probably an infinite number of ways to do things. What I typically do is to have a “reset” method that can clear one or more sets of data. This could be done by clearing each ViewState variable, or clearing the property if it is not set to ReadOnly.

Then, every time you need to get the data again, just call reset_record_list, and the next time record_list is referenced, the data won’t exist and it will try to retrieve the data automatically.

The great thing about this is that if you have several data sets that all are referenced at different times throughout the page cycle (or maybe not at all, depending on user input), the database will only be hit when necessary.

Like this post? Share it!