Click here to Skip to main content
13,298,842 members (38,641 online)
Click here to Skip to main content
Add your own
alternative version


29 bookmarked
Posted 5 Nov 2009

Line-Of-Business Applications with ASP.NET

Rate this:
Please Sign up or sign in to vote.
A new approach in business applications development with ASP.NET is presented.


In this article, I would like to discuss the challenges we faced developing business applications with ASP.NET and what we have done to make life simpler. By business applications, I mean loads of interrelated forms, grids, trees, and so on. Let's make a thought experiment: Imagine we have to develop a new CRM from scratch. A CRM should have a web interface, it should show customers, register orders, print reports, and so on (just usual stuff). How are we going to implement this?

As we are going to use ASP.NET, let's follow the straightforward way and look where it leads us; that's how our application initially looks:

Initial application structure

Very quickly, we discovered that the same functionality is needed at several pages. For example, a grid with customers is useful at both Customers.aspx and CustomerSelectDialog.aspx. Fortunately, it's not a problem: there are user controls in ASP.NET, so we refactor .aspx pages to .ascx user controls, which makes them reusable. We also noticed that using .aspx pages gives us no advantages compared to .ascx user controls, so we refactored everything to user controls.

User control structure

And, if there is still some code duplication, we can create smaller controls and combine them for bigger controls and so on... Once this was done, there was no more code duplication, but the application structure started getting more complex:

Complex user control structure

Usually, having a complex application structure is OK as long as each component is simple; I think of it just like normalization. The problem is that these user controls are absolutely not testable, though they contain code that can be tested. The solution is obvious and well known - testable code should be extracted to special testable classes. I would like to illustrate the concept with a sample:

public partial class CustomerRegistrationForm : System.Web.UI.Page 
  protected void OkButton_Click(object sender, EventArgs e) 
    var customer = new Customer { Name = Name.Text }; 

(Please do not think we've really developed a CRM and shipped something like this, it's just a sample.)

Obviously, this form registers new customers in the system. Now, let's refactor it into make something testable. As the MVC pattern is increasingly popular, I used the same terminology:

public class CustomerController { 
  public void CreateCustomer(string customerName) 
    var customer = new Customer { Name = customerName }; 
public partial class CustomerRegistrationForm : System.Web.UI.Page 
  CustomerController controller = new CustomerController(); 
  protected void OkButton_Click(object sender, EventArgs e) 

Wow! The application logic is now testable! We can do the same thing with our imaginary CRM. Let's create a Controller for each user control, and this is what our application structure looks like:

Just great, isn't it? Unfortunately, it is not. It does not take long to realize that the most breakable application logic is the interaction between the controllers and it is still not testable. The problem is that the presentation layer is still a decision maker. Everybody knows that the presentation layer should be thin and simple, but how do we achieve that ? If you have heard of "Inversion of Control", the solution lies on the surface: revert the arrows in the image above and let the controllers rule the application.

Initially, the controllers were created and used by views; after refactoring, they should create and use each other, they also should know as little about the Views as possible. So, we can create a controller tree in the test environment, replace the Views with mocks, and have the application running almost the same way as it does in production. Of course, the Controller and View should be loosely coupled, which requires an intermediate interface to be introduced.

In the figure above, I renamed CustomerController to CustomerForm and CustomerForm to CustomerView to emphasize that the controller is not just a helper for the presentation anymore. And, let's use the term "Component" for the controller; that's where the real fun begins. Imagine that "Components" just work and we once again refactor the CRM to make it Component based. Now, the code is testable (except Views) and clean because the application logic is now separated from the presentation. The next thing we notice is that all grids in the application look alike or at least should look alike. Why not create a configurable Grid component for them all ? In this case, we can create grids without implementing the View every time; this would make our code not only nice, but also compact. For example, this is how the Grid component would be used:

var grid = new Grid<Customer>();

Of course, we like the result - the code is small, testable, there is no HTML or JavaScript, and all our grids look alike. Moreover, if we need a new feature, we can implement it in one place and it will appear everywhere. Of course, we can't help but do the same thing with all the components. Eventually, we have a basic set of components which should be just configured, and the new Form or Grid or Tree is ready. The basic Components have nothing to do with CRM, so we move them to an independent module. That's what our CRM turns into:

That's it. Our application is testable, all code looks clean, just one step left. If we have a module for building business applications where all the infrastructure is implemented, why not share it with other developers? We decided that this is good idea; the above discussion was just a fiction, but the results are real. We indeed implemented Components and Views, organized them in modules, and shared them through a web site. You are welcome:


This article, along with any associated source code and files, is licensed under The MIT License


About the Author

Alexandr Sergeevich Ilyin
Software Developer Xtensive
Russian Federation Russian Federation
I've been working at Xtensive company for 3 years.
My current project is LiveUI web framework which should make everybody happy. If I can be of any help to you feel free to contact me alexandr.ilyin at

By the way, I have a blog.

You may also be interested in...


Comments and Discussions

GeneralRe: Comments Pin
Alexandr Sergeevich Ilyin6-Nov-09 1:57
memberAlexandr Sergeevich Ilyin6-Nov-09 1:57 
GeneralRe: Comments Pin
Md. Marufuzzaman6-Nov-09 4:41
groupMd. Marufuzzaman6-Nov-09 4:41 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.171207.1 | Last Updated 6 Nov 2009
Article Copyright 2009 by Alexandr Sergeevich Ilyin
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid