We write many lines of code in the code behind file of asp.net page or user control file. Sometime we incorporate huge business logics in these pages from time to time. Consequently, the codes of these pages turn into in a mess, As a result, we encounter some obvious problems
-Difficult to add new business logics.
-Unable to reuse methods from page code behind file to another page code behind. Consequently, we copy and paste the logics or methods to another page.
-Difficult to test the component programmatically
-Lots of “if” statements related business which create code smell.
-Lost readability or manageability
-Code is not self-explanatory.
-Lack of programmatically testability
-Business logicless page code behind file.
Gradually, we can improve our code in small scale when we work on maintenance work or we can plan for an iteration for huge refactoring work. Keeping this in mind, we refactored code of a user control which is being used several places and has many business logics for displaying content in this component.
Here, we have refactored such a reusable component (UserControl) where lots of code and logics were increasing as per requirement changes.
Now the component refactored with OOP technique and design pattern. We all know about many design patterns but a very few usage of them in your application. This is because of a victim of time constraints or lack of scope to write coding in such way or lack of practicing standard coding. However, we tried to implement some sort patterns.
The followings are the short version of the requirements:
- General content has few attributes. Left content, right content, style, mobile style. These attributes are populated in different ways form different pages.
- This general content will be pulled from a common configuration stored in the database, and it will be displayed in several pages.
- For a particular page, the content will come from page wise configuration if the page wise configuration exists for the page. Otherwise, the content will be pulled from the common configuration.
This scenario is implemented using some sort of abstract factory pattern design mechanism, and the whole code from UserControl code behind are shifted to class library so that presentation layer's code remains more clean.
It has a common "GetGenericContentModel" method which return "GeneralContentModel" model which all the information for presentation layer. For a new service, this interface class will be implemented to return the data the presentation layer.
It implements IGenericContentService that reads configuration from database and which has several methods to process configurations
It implements IGenericContentService that reads another set of configuration from database and which has several methods to process configurations which is suit for this configuration and it overrides some method of GeneralContentService
This class has a method and it's responsibility is to return a concrete service for general content which holds actual logics of data processing for common pages.
It contains the logics to return the service for the measure page (specialized page) which holds actual logics of data processing for the measure page.
It takes base service builder and return the actual " GeneralContentModel" model. Different pages provided different service builder instance and in return it gives the "GeneralContentModel" model for the page.
Since different pages provided different service builder instance to the UserControl so the control create instance of "GeneralContentManager" passing the service instance and get the "GeneralContentModel" which contains everything for the UserControl.
var manager = new GeneralContentManager(generalContentServiceBuilder);
var generalContent = manager.GetGenericContentModel();
//Code for displaying general content information.
-Easy to adgust business logics for new page to populate the general content.
-Increase maximum code reuseability.
-Increase readability and manageability.