I am writing a simple ASP.NET Web Forms application. I want to improve the code by implementing any design pattern with which abstraction is achieved and increases manageability and understandability.
Which pattern is recommended? Please also provide links to sample applications.
You might consider using the Model-View-View Model MVVM pattern. It is a derivative of MVC, but is designed / intended to be used in exactly the situation you describe. There is a wealth of information on the MSDN site if you don't feel like googling it.
MVVM facilitates a clear separation of the development of the graphical user interface (either as markup language or GUI code) from the development of the business logic or back end logic known as the model (also known as the data model to distinguish it from the view model). The view model of MVVM is a value converter meaning that the view model is responsible for exposing the data objects from the model in such a way that those objects are easily managed and consumed. In this respect, the view model is more model than view, and handles most if not all of the view’s display logic (though the demarcation between what functions are handled by which layer is a subject of ongoing discussion and exploration). The view model may also implement a mediator pattern organising access to the backend logic around the set of use cases supported by the view.
With ASP.NET Web Form, you typically use the Model View Presenter pattern.
GlenH7 mentioned in his answer MVVM; while it is an elegant pattern, ASPX Webform just doesn't have great support for that. MVVM is more popular in the WPF world.
Short answer: look at the MVP pattern that avoids potential code-behind ASP.NET forms issues by loosely coupling (de-coupling) your view and logic.
You may also want to go one step further and look at this comparison: MVC, MVP, ASP.NET.
The following posts are good entry points and examples:
The one thing you need to avoid at all costs is the WebForms anti-pattern of putting logic in your code-behind. Whether you use MVP or a flavor of that or not, your code-behind files should be very sparse for the sake of your sanity.
However ... your stated requirement is very abstract:
I want to improve the code by implementing any design pattern with which abstraction is achieved and increases manageability and understandability. ...
... and to those ends you seem to be looking to "design patterns" as being some kind of recipe. You even cite "abstraction" as a requirement.
The already-existing code found in an already-existing application usually does not benefit from attempts to "improve" it. You need to fully-ground your efforts – not in abstractions like "design patterns" – but in the application itself, exactly as it stands now.
Over many decades, I have looked at more than fifty different applications that were or still-are in service and I can see the "silver bullets" of yesteryear as they came and went, each one imposing a "new" way of doing things that never actually replaced anything. Both methods are still there. "Manageability and understandability" would have been greatly improved in the long run if this-or-that "silver bullet" had never been attempted at all.
The entire concept of "design patterns," in my view, is that they are a way to ignite useful conversation and to suggest possible alternatives. But they are not recipes.
MVVM is possible in. NET 4.5 with model binding and the use of templated bound controls like FormView.
Here is the technique I use:
I design ViewModels for each UserControl and nested UserControl and then use a FormView that is always in EditMode, where I include the controls that bind to model properties using Binding expressions.
I set the SelectMethod and UpdateMethod of the FormView. The first returns the ViewModel and the 2nd calls TryUpdate() on it. On postbacks I always call the FormView's Update method in Preload or Load. In that way the ViewModel is always up-to-date from the view.
I run the logic inside the ViewModel and on PreRender I rebind the view to apply any changes. The key in this method is to inject the ViewModel into the view (UserControl) outside the view (ex. in Page level) and of course ensure that is serializable and cached in ViewState or any other place I choose.
Finally I disable the ViewState in all controls since they are ultimetaly "driven" by the cached stateful ViewModel and don't need their own state.
This technique never failed me so far and I only wish I could find a solution for command/button binding too, like WPF.
