Is it good choice to structure a large Asp.net MVC application using Areas?

Question

Each Area will have its own config etc. So as the areas increases, the complexity and maintainability increases as well. Will it be good choice to modularise or partition and MVC application functionality in to Areas or continue with traditional Controller/View approach?.

Please suggest a common solution or better way to architect a large scale MVC application.

Answer 1

There is no rule on whether to use Areas or not, it's basically up to solution architect to do an estimate should using areas provide benefit or not.

Our latest project that involved areas, included 3 different types of users working on the website. We used controller naming scheme where controller name matched the resource name (i.e. CategoryController).

However, certain resources could have been accessed by all 3 user groups in completely different manner: one user group could only list resource, other user group could manage them (basic crud) while the 3rd user group (admin-like) could do advanced features such as exporting, importing, etc...

By separating the functionalities in areas, we've reduced security problems by simply decorating the controller in area to request user type specific for that area, in order to avoid mixing of permissions. Doing it on the base controller for the area, made things even more centralized.

That is one reason why we would pick separation of areas.

On the other hand, we've often been in situation where we have request for a high-demanding public website and "back-office" internal configuration website. For the performance and scalability + concurrency issues, we've quite often designed public website that could be load balanced as a one project, and back-office website that would be only hosted once as a second project - instead of using areas.

Again, this is just one approach from the industry, not necessarily the optimal approach.

Answer 2

Areas shouldn't be confusing, and certainly aren't redundant. As you say, they allow you to partition your web app into smaller functional groupings. This is extremely helpful when the size of your applications grow and a single application umbrella becomes unwieldy.

As an example, I have just completed a large application that stored promotional data for various retailers across North America. The US and Canada sales teams are isolated, but are executing their tasks in nearly the same business contexts.

It made a lot of sense to partition the US and Canada parts of the web app into Areas, which organized things a lot better for us. Each area could still use the same components where they make sense (repositories, services, etc...), but the isolation Areas brought allowed us to build separate controllers and views specific to each business group, instead of trying to run a bunch of logic checks to accommodate whatever region the user was in.

Answer 3

Here is possible alternative to your approach from "Programming ASP.NET MVC 4" by Jess Chadwick, Todd Snyder, and Hrusikesh Panda:

There are many different approaches to take when designing an ASP.NET MVC application. A developer can decide to keep all the application’s components inside the website assembly, or separate components into different assemblies. In most cases it’s a good idea to separate the business and data access layers into different assemblies than the website. This is typically done to better isolate the business model from the UI and make it easier to write automated test that focuses on the core application logic. In addition, using this approach makes it possible to reuse the business and data access layers from other applications (console applications, websites, web services, etc.).

A common root namespace (e.g., company.{ApplicationName}) should be consistently used across all assemblies. Each assembly should have a unique sub-namespace that matches the name of the assembly. Figure 5-4 shows the project structure of the Ebuy reference application. The functionality for the application has been divided into three projects: Ebuy.WebSite contains the view, controllers, and other web-related files; Ebuy.Core contains the business model for the application; and the CustomExtentions project contains the custom extensions used by the application for model binding, routing, and controllers. In addition, the project has two testing projects (not shown): UnitTests and IntegrationTests.