Special Capabilities in Visual Basic .NET

Create QR Code JIS X 0510 in Visual Basic .NET Special Capabilities

As you have seen, the primary purpose of a controller is serving the needs of the user interface. Any server-side functions you need to implement should be mapped to a controller method and triggered from the user interface. After performing its own task, a controller s method selects the next view, packs some data, and orders it to render. This is the essence of the controller s behavior. However, other characteristics are often required in a controller, especially when controllers are employed in large and complex applications with particular needs, such as frequent updates to the user interface, numerous commands to deal with, or long-running requests. The following section covers additional capabilities you can take advantage of when working with controllers.

How many controllers do you expect to have in your application The answer mostly depends on the complexity of the application. Suppose you have 50 controllers (and assume that you ve balanced the responsibilities well among controllers). Typically, you end up with all of these 50 classes packaged within the single Controllers folder of the project. And what about views Under the single Views folder, you will find up to 50 subfolders, each with a bunch of view templates such as ASPX files. In a nutshell, your project is quite messy and hard to manage. Most of the time, a single Controllers folder is enough for many maybe most applications written with ASP.NET MVC, but sometimes it s not enough. As of ASP.NET MVC 1.0, there is not much you can do to split the project, or just controllers, into distinct folders. A few attempts have been made by prominent members of the ASP.NET community to find an effective way to partition controllers into groups without breaking the routing capabilities of ASP.NET MVC. In ASP.NET MVC 2, however, a new feature has been added that addresses exactly this point.

Areas provides a means of partitioning large applications into multiple blocks (named areas), each of which can be developed independently. From the perspective of developers, an area provides a way to group controllers (and related views) in smaller and more manageable collections. The whole idea of areas is nothing new, as it was a feature originally offered by Castle MonoRail an open-source Model2-based framework for building Web applications on the .NET platform. (See http://www.castleproject.org/monorail.) According to MonoRail, all controllers always belong to an area and any project consists of at least one default and unnamed area. Note One could even cynically say that the whole idea of ASP.NET MVC is also nothing new. On the other hand, isn t this what I repeatedly pointed out in 1 and 3 ASP.NET MVC builds on top of the Model2 pattern created some 15 years ago for Java Server Pages and more recently revamped for the .NET platform by Castle MonoRail. But it does add some nice goodies of its own.

Software, like science, has an inherent cumulative nature: what you do today can possibly inspire someone else tomorrow to build a similar-but-improved product which, in turn, might inspire you and so forth in what is hopefully an endless chain. A graduate instructor of mine summed it up when he said, As for software reuse, steal everything you can.

The ability to group controllers in areas is beneficial also because it leads you to partition your application into discrete functionalities. If you feel the need to go beyond the default

single group of controllers, you are forced to think in terms of logical functionalities that emerge out of your requirements. When areas are used, an application grows up as a collection of distinct applets managed under the umbrella of a single solution. This said, I feel the need to reinforce the key statement about areas. Areas are not for just any application. Areas come to the rescue when you are having a hard time taming dozens of controllers and views. If your application deals with blogs, forums, and news logical sections, you might want to dedicate an area to each in such a way that each area can be architected and developed in relative isolation with no naming conflicts between controller classes and view templates.