What is the right way to develop ASP.NET applications in order to separate data access from data visualization?

Question

I'm currently involved in a migration to TFS from SVN of a large project that is going to be divided into five different sites. This project allows some providers to insert five different product data into the enterprise DB. Like a lot of companies out there, we have a technological debt that should be solved (or at least, reduced) with this new project organization. However, I'm quite new to ASP.NET and also our software is still running 2.0 .NET, so maybe I'm missing something or things should be done in a different way nowadays with 3.5+.

One of those five different parts is going to be a new one. This is the one I'm going to develop. In order to achieve high degree of modularity, the code of the current project is divided into several DAO (Data Access Object) under App_Code, *.ascx modules living in different parts of the project structure, VB classes that inherit from System.Web.UI.* (for each control that is displayed on the web) under App_Code, and lots of stored procedures for providing data to the controls. Also, we have several *.aspx that use <asp:PlaceHolder /> for displaying each of the controls that inherit from System.Web.UI.

The question comes when, for creating a simple <select> dropdown list to display a list of providers, I see that I have to do the following steps:

1. Create a class cProvider inside the App_Code, that ultimately inherits from System.Web.UI, with a method that calls to the following DAOProvider object.
2. Crate an specific DAO object to connect to the DB I need to.
3. Create another DAO object, called DAOProvider, that inherits from the previous one, with the call to an stored procedure that retrieves the list of the providers.
4. Create that stored procedure in the database.
5. Create an .ascx control to display the <select> with the options obtained from cProvider.

If you're still there, here goes my question: Is this the right way to do things? Is this high level of modularity the correct way to develop mantainable .NET applications? Do I have to follow this style and organization or should I take another one (please give me your recommendations)?

From my point of view, having to do all those steps to paint a simple dropdown list doesn't follow KISS principles at all, and becomes unmantainable if somebody else has to take this project, knowing that the code is the only documentation we have.

EDIT: links to documentation regarding this topic would be highly appreciated.

Answer 1

I really don't want to just repeat David, but MVC is the way to go when clear separation of responsibility is important. It divides your architecture into three areas: The models (your classes), the views (think of these as your webpages), and the controller (the logic).

I realize switching may not be possible. In webforms, which is where your question comes from, it is possible to be modular without going overboard. I can't point to any specific examples, but yes, it sounds like your current project is way over-architected. Even before ASP.NET MVC, there were "MVC-ish" ways of doing ASP.NET webforms with good separation of responsibility.

My best recommendation is don't repeat yourself. If you're going through five steps to instantiate a dropdown, take a good hard look at ways you can wrap some (if not all) of those steps into a simpler process. Generics are a godsend for this.

Lastly, going back to the MVC recommendation, remember that you can and should mix ASP.NET webforms and MVC when appropriate.

Answer 2

Modular starts well below the waterline. If you are debating MVC vs. WebForms you have already lost the war.

What you want to do is separate the core, non-UI parts of the project into a separate assembly with no reference to System.Web.UI or anything of that sort. The UI layers reference this assembly and call it's methods which should generally be returning POCOs and collections of POCOs. The UI that sits on top of this layer can then be a relatively simple throwaway. Remember, UI changes every 3-5 years whereas core data storage and logic can last decades.

To get at your drop down list you would:

a) Define a class for your drop down list data -- we actually have a pretty generic construct that has the right things one needs, YMMV.
b) Define a data service class responsible for accessing the specific data with appropriate methods.
c) In your page / MVC controller, access the service and the service method and put the data in an appropriately accessible object.
d) In the template, access the object and render the <select>

If it is a list you use often, you might want to consider making a user control / partial view / child action as required. My experience is modularity really starts falling down in the UI layer where one oftentimes ends up making horribly complex things to handle customization that would have just been best left hand-wired over some good core logic.