Best practices for developing a well-organized modular ASP.NET application

Question

I'm trying to think about the web application development framework for developing our product. I want to create an ASP.NET application that has many submodules. My requirements:

• The application will be a set of various modules, such as CRM, Bugtracker, inventory management, financial management, etc.

• Each module must have its own DLL.

• One project should be for an external application container (for example, a framework), and this project should bring all other modules (such as a web application) into a solution to an external container. (Some things like we have frames in HTML). Thus, we will publish an external container web application only at the end of the day, and through it all other web application projects will be available.

I would like to have a separate DLL for each module, so I don’t need to be afraid of an application crash when I deploy my only DLL that manages the whole package.

I'm not sure my thoughts are in the right direction. The end result I'm looking for is a well-kept, organized, and modular web application package.

These are ASP.NET web forms, not MVC. I will use VS2010 for development.

What are the best approaches to this?

Edit:

The term external container means that it acts as a main page that has links to various modules, and different modules are not always in the same project. They can be a separate project under the same solution. And I get the impression that by the end of the day I will publish only this project, and it will bring various modules to it.

Answer 1

In fact, I think that the best approach would be that it does not redesign. I am worried that it seems that you are producing a common architecture without good reason.

Are these new modules? Then just start writing first. Use the best practices applied to individual modules.

Then write the second. You will find that you want to use what you already wrote in the first module. Fine. Why refactoring is needed. Refactor these things into one or more "library" projects, repeat all your unit tests, and then go to the second module.

Repeat until all modules are complete.

At the end of this process, if you need the architecture that you have outlined, you will get it. If you need less, then you will have less, and you will not spend time creating an architecture that is not tied to real requirements.

Answer 2

I am not going to say that this is the “best approach”, but I would recommend looking at Dot Net Nuke (DNN) to get some ideas. It started with the old start-up web project, "I Buy Spy", which Microsoft distributed to showcase ASP.NET projects, and it took off from there.

edit:

1. The application will be a set of various modules, such as CRM, Bugtracker, inventory management, financial management, etc.

You can do this with DNN. They are also called "modules" in DNN and Drupal.

2. Each module must have its own DLL.

Yes, that's a good idea. And you will see this in several content management systems such as DNN and Drupal. Thus, not all implementations of the same website must have all modules.

We have a significant website that is used to host the service as a solution application, for which we charge a fee (unless you are an actuary or accountant that you have not heard of). The lead developer over the past couple of years has used an earlier version of DotNetNuke as a model to reorganize the parts of the application that he was allowed to change.

Answer 3

Like others, DNN is likely to work on what you are trying to do. If you want to completely roll on your own, I would turn to some combination of the "Framework" container and a bunch of user controls (.ascx). A container can be as simple as a main menu page. Depending on how flexible you want your design, you can pre-assemble many different pages, each of which has a separate control (a separate dll, as you wish). If you want it to be a little more dynamic, you can have one page of content that will dynamically load the required user control at runtime. Again, this is just a general approach, perhaps 30,000 feet in how DNN is implemented anyway.

Answer 4

Name the main project after your company / product and keep it short and simple. You will probably need one or two library projects to support it - they will contain daily common logic for error messages , web utility methods, etc.

Then select one of your planned subprojects (I don't like the term module in this specific context) and add that to your solution. If you reuse an existing project or, preferably, start from scratch, in the end you will have some kind of common logic in this project, transferred to your libraries.

Rinse and repeat. Perhaps look at something similar, such as the Sueetie project, which includes several subprojects such as CMS, blog, calendar, forum, etc.

The following article has been marked "obsolete" on MSDN, but I still think you should take a look at it:

Structuring solutions and projects

In addition, something similar to a group of patterns and practices:

Structuring projects and solutions in Team Foundation Source Control