Extreme ASP.NET Makeover: SoC - The Big Picture
- Posted: Jul 10, 2009 at 4:40 PM
- 10,517 Views
Right click “Save as…”
Let’s summarize what we’ve done. We removed code from Page_Load using cut and paste, and we created two new classes. It doesn’t seem like much as far as refactoring is concerned. But that’s because we aren’t actually finished with the task. In order to consider the work complete, we must now go to every page that made use of AuthChecker and do the same refactoring as we did here. It will be a lot of work, but the method we used to separate the authorization-specific code can be incrementally applied to other code behind files. Let’s take another look at the refactoring, but this time we’ll see how automated refactoring tools can assist with the changes.
Once all of the uses of AuthChecker have been removed and AuthorizationService is being used in its place, you will have made the codebase much simpler to work with. Consider now what is involved when we change how permissions are retrieved. Instead of having to find and change the many places that AuthChecker was originally being used (over 130, by our count), you can work only in the AuthorizationServices class. This single point of change shows that you are more likely to be separating the concerns in your codebase.
In the end, a few things have happened from when we first looked at the Default.aspx.cs Page_Load method. First, we have been able to clearly define an area in code for the authorization concern. When anything related to determining a user’s authorization arises, we know that it will be taken care of by the AuthorizationServices. No longer will we continually suffer the ripple effects of modifying or fixing the functionality related to this concern.
Second, we have reduced the number of lines in the Page_Load method, yet through the use of revealing variable and property names, we haven’t reduced the ability for developers to decipher the intentions of the code. This is quite important when doing this type of refactoring. You never want to leave code less understandable than when you found it. (And considering how quickly comments become obsolete, leaving a trail of them behind you to ease understanding is not an optimal approach.) Instead, think about how you will use variables, properties, and methods in the code and name them so that they read and convey ideas easily.
The final achievement is that we have started a trend of reducing repetition in our codebase. This is a side effect of separating our concerns, but by implementing an isolated class whose sole responsibility is to determine user authorization for a given page, we are allowing ourselves to eliminate any repetitive code that is also doing this. A simple Find search for “AuthChecker” in the entire solution shows that many locations can benefit from using the new AuthorizationServices class.
Taking care of the authorization concern is just one of many refactoring tasks that are available in the Page_Load method of Default.aspx.cs. Others include the URL redirection, the URL builders, Content.GetPageContent, and Settings. If you look through the code provided with this article, you can see how we have refactored those concerns out of Page_Load so that it has one, and only one, reason to change: how we are displaying the contents of the page.
Read the full article at http://msdn.microsoft.com/en-us/magazine/ee210417