AREAS in ASP.NET MVC 2.0

Until ASP.NET MVC 1.0 we have some default folder structure that ASP.NET MVC runtime expects to be. All the controller classes to be in the controller folder and views should be under views\controllerName folder. We really want to group the controllers & views based on the functionality because we don't want to have all under single folder, more over it will become difficult for us to find the functionality. To resolve this problem ASP.NET MVC 2.0 has a very interesting and useful feature named AREAS. Areas are like modules in application software. This has made the developers and architects to work on different modules without disturbing the others. What is this something to ASP.NET MVC?
We have been working on different modules in asp.net web farms by creating folder for each piece of functionality in asp.net application. This cannot be done in ASP.NET MVC, we don't have the flexibility to create folders as our wish. The reason being, ASP.NET follows convection over configuration.


Separation of Concerns is a solution of the problem, not in terms of technical but in terms of conceptual. Over the time technical geeks has spent time in customizing the MVC 1.0 framework for getting this flexibility. Now this has been given as a feature in Asp.NET MVC 2.0, which is important and widely accepted feature in community.

So how Areas are defined? And how are they are different in terms of URLS? In 1.0 for the entire project we have one folder for controllers and one folder for views. Now in 2.0 the basic rule remains the same but the rule is modified to area. So you can create different areas. In Web project there is folder called Areas which contains different areas folders named by area name.


Namespaces in Areas
There is a strict rule in terms of naming areas.
Every area should be defined in
<Application namespace>.Areas.<Area Name>.
Controllers should be defined in <Application namespace>.Areas.<Area Name>.Controllers


URLS in Areas
Let's go to the actual problem, if the application is big and has may URL Routes, it's difficult to maintain all routes in one location which is global.aspx. Developers have to take an effort to group routes and maintaining this is an issue.
In MVC 2.0 we can define the Area specific routes under the area folder. For every area you have a class file by name <AreaName>AreaRegistration.cs . The class defined in this file is extended from a mvc framework class AreaRegistration. We can define all the routes in below method

 

Area URL Registrations


public override void RegisterArea(AreaRegistrationContext context)
{
context.MapRoute(
"ConsolidatedInvoice_default",
"ConsolidatedInvoice/{action}/{id}",
new { controller = "BAB", action = "SelectInvoices", id = UrlParameter.Optional }
);



Migration of code from 1.0 to 2.0 Area
There is no migration tool to migrate from 1.0 version to 2.0. When I tried migrating project, I just moved the files from root level folders to area level folders, the process failed to run because runtime expects namespaces to be in the above formats. It tries to load the specific area controller by looking into the URL and namespaces. We have to takecare the namespace issues manually.


Web.Config in Views folder
Pages also called views are available in the views folder. In MVC views are not directly exposed to outside by URLS. All the view requests should go to the controller and it will render the exact view using the inputs from URL. Views are normal asp.net web pages, so they can be accessible a URL. To restrict direct accessing of views, we use web.config file in views folder. The web.config has a default handler mapping to blocks all the pages which has extension ASPX. If we want to add restrictions to other types of files we can add a handler mapping for the extension and HttpNotFoundHandler. We need to modify the mappings at two locations for IIS6, IIS7(Classic Pipeline) and IIS7 Integrated Pipeline.


Web.config mappings

//For IIS6, IIS7(Classic Pipeline)
<httpHandlers>
<add path="*" verb="*"type="System.Web.HttpNotFoundHandler"/>
</httpHandlers>


//For IIS7
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<handlers>
<remove name="BlockViewHandler"/>
<add name="BlockViewHandler" path="*" verb="*" preCondition="integratedMode"
type="System.Web.HttpNotFoundHandler"/>
</handlers>


Web.Config in Area folder
Similarly for views, there is a web.config file for each area serving the same purpose. This is to restrict access of ASPX files. If we don't want to restrict them at area Level, we can delete this web.Config file.


Application settings in Web.Config
There are many web.config files; can we have application settings of areas in area specific web.config file? The answer is No, we cannot or have or override the appsettings configurations. All the application settings should be defined in the web.config of the root folder
 Authentication & Authorization in AREAS
Sometimes we need to have different security permissions to different areas; this can be achieved by <Location> element in web.config file. This concept is not new in MVC, it has come from asp.net. There is one difference between Web farms and MVC in terms of path for the location Element.
  1. In Web Farms for path attribute corresponds to folder or page relative path
  2. In MVC since we don't deal with folders, path attribute corresponds to URL. We need to mention the Area Name in path, since all the URLS of an Area starts with the Area name

    <location path="Area1">
        <system.web>

    </system.web>
    </location>
Authorization in Web.config

<location path="Area1">
<system.web>
<authentication mode="Windows" />
<authorization>
<allow roles="role1,role2"/>
    <deny users="*"/>
</authorization>
</system.web>
</location>


<location path “Area2">
<system.web>
<authentication mode="Forms">
  <forms loginUrl="Logon.aspx" name=".ASPXFORMSAUTH">
  </forms>
</authentication>
<authorization>
  <allow roles=" role3,role4"/>
  <deny users="*"/>
</authorization>
</system.web>
 </location>

All other things like master page creation, Error handling works same as in MVC 1.0

Please provide your valuable comments.

2 comments: