Menu
I am working on an agile MVC3 project and it is starting to get rather large, specifically my management section, where the user is able to set a lot of configurations, etc. This is my first MVC3 project, so I am just curious when it makes sense to use areas?
Like how large should a controller for a specific section like management be before you decide to break it up into an area and create controllers for the individual management operations?
Also, when using areas, should I refactor to use areas for everything, or just for the sections that need an area?
569
Area allows us to partition the large application into smaller units where each unit contains a separate MVC folder structure, same as the default MVC folder structure. For example, a large enterprise application may have different modules like admin, finance, HR, marketing, etc.
Areas allows you to separate your modules and organize Model, View, Controller, Web. config and Routing registration file into separate sections. In live MVC Project implementation we can use Areas concept for organizing project in better manageable way. Area separate logical section like Model, View, Controller, Web.
ASP.NET MVC 4 is a framework for building scalable, standards-based web applications using well-established design patterns and the power of the ASP.NET and the . NET framework. This new, fourth version of the framework focuses on making mobile web application development easier.
There are as many opinions about how to organize this as there are developers, but my views are as follows;
Controllers should only be responsible for interacting with views. That is, instantiating and populating model objects, retrieving data from your business objects or data access layer, responding to any requests from the page (form submissions, AJAX requests, interface to dynamic resource creation methods/classes (such as creating CAPTCHAs or other dynamic images)), etc. If you stick to that philosophy, their size and complexity should never exceed that of your views.
Areas I tend to use areas to break up the application into sub-applications. For instance, a site may have a discussion forum, product catalog, company information, support database, etc, all of which would be separate areas:
/areas/forum/... /areas/product/... /areas/company/... /areas/support/... Then, in each area, you might have
/areas/support/{views|controllers} /areas/support/search/ /areas/support/contact/ /areas/support/knowledgebase/ etc.
Just as in a webforms site where each folder represented a distinct "area" of the website, areas provide another level of organization that lets you keep related controllers, views, etc in a common location, and should be used in a similar fashion.
88
We use areas to distinguish notable separate concerns within the application. Especially separate concerns that may require unique authentication or layout/styling for each area. For example, I'm working on an application that has "modules" of sorts. Each module is an mvc area and each module as a setup section that is also an mvc area. The application has three modules, so that is a total of six areas -- with six user rights to go along with them. This allows each module to have a new "master page/layout" (appearance) and a specific security level.
It helps in separating the code as well; code in AreaA has nothing to do with code in AreaB, but sometimes AreaA and AreaB use common code found in the root of the project.
The non-area parts of the site have things like the user-login, error pages (404, etc), the main "launcher" area to enter the modules, exception handing, and other encompassing things that cross-cut across any of the mvc areas.
20
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
