MSDN Magazine - February 2009 - (Page 43)

4. Select the proper view, and marshal the model data generated from the controller method to this view. 5. Render the view. Out of the box, there is some repetitive ceremony in building Web pages with the ASP.NET MVC Framework that you can mitigate by adopting some restrictive conventions. The first task is to connect an incoming URL to the Web site with the proper controller class. The Routing library in the MVC Framework can interrogate a URL and determine the name of the controller. The MVC Framework will then ask the registered IControllerFactory object for the controller object that matches the controller that matches the controller name determined from the incoming URL. Many teams simply delegate controller construction to an inversion of control (IOC) tool. In my team’s case, we use the open source StructureMap tool for resolving controller instances by name: public class StructureMapControllerFactory : IControllerFactory { public IController CreateController( RequestContext requestContext, string controllerName) { // Requests the named Controller from the // StructureMap container return ObjectFactory.GetNamedInstance ( controllerName.ToLowerInvariant()); Figure 6 New Conventions for StructureMap /// /// This code would be in the same assembly as /// the controller classes and would be executed /// in the Application_Start() method of your /// Web application /// public static class SampleBootstrapper { public static void BootstrapContainer() { ObjectFactory.Initialize(x => { // Directs StructureMap to perform auto registration // on all the Types in this assembly // with the ControllerConvention x.Scan(scanner => { scanner.TheCallingAssembly(); scanner.With (); scanner.WithDefaultConventions(); }); }); } } } } Requesting the controller is fairly simple, but first you need to register all of the controller classes by name with the IOC container. Wait! Isn’t that adding some ceremony to the architecture? A year or two ago I would have plunged ahead with explicit IOC configuration of the controller classes like this: public static class ExplicitRegistration { public static void BootstrapContainer() { ObjectFactory.Initialize(x => { x.ForRequestedType ().AddInstances(y => { y.OfConcreteType ().WithName("address"); y.OfConcreteType ().WithName("contact"); // and so on for every possible type of Controller }); }); container with the new convention, as shown in Figure 6. Once the new ControllerConvention is in place and part of the IOC container bootstrapping, any new controller classes that you add to the application are automatically added to the IOC registration without any explicit configuration on the part of the developer. So there are no more errors and bugs because a developer forgot to add new configuration elements for new screens. As a side note, I want to explain that this strategy of auto registration is possible in all of the IOC containers that I’m aware of for the .NET Framework as long as the IOC container exposes a programmatic registration API. Next Steps } } This code represents pure tedium and ceremony that exists for no other reason than to feed the IOC tool. If you look closer at the registration code, you’ll notice that it’s following a consistent pattern. AddressController is registered as address and ContactController is registered as contact. Instead of explicitly configuring each controller, you could simply create a convention for automatically determining the routing name of each controller class. Fortunately, there’s direct support in StructureMap for conventionbased registration, so you can create a new ControllerConvention that automatically registers any concrete type of IController: public class ControllerConvention : TypeRules, ITypeScanner { public void Process(Type type, PluginGraph graph) { if (CanBeCast(typeof (IController), type)) { string name = type.Name.Replace("Controller", "").ToLower(); graph.AddType(typeof(IController), type, name); } } } In the end, it’s all about reducing the distance and friction between your intention and the code that makes that intention happen. A lot of the techniques I showed in this column are really about letting the code “just figure it out” from using naming conventions instead of explicit code or finding ways to avoid duplicating information in the system. I also used some reflective techniques to reuse information buried in attributes to reduce the mechanical effort. All of these design ideas can reduce the repetitive ceremony of the development effort, but it comes at a price. Detractors of convention over configuration complain about the inherent “magic” of the approach. Embedding opinions into your code or framework will detract from potential reuse in new scenarios where those opinions aren’t as favorable. There were a lot of other topics that I was unable to cover this time that I may cover in a later column. I definitely want to explore how language-oriented programming; alternative languages such as F#, IronRuby, and IronPython; and internal domain-specific language usage affects the software design process.  Jeremy miller, a Microsoft MVP for C#, is also the author of the open source Next, you need some code that bootstraps the StructureMap msdnmagazine.com StructureMap (structuremap.sourceforge.net) tool for Dependency Injection with .NET and the forthcoming StoryTeller (storyteller.tigris.org) tool for supercharged FIT testing in .NET. Visit his blog, The Shade Tree Developer, at codebetter.com/ blogs/jeremy.miller, part of the CodeBetter site. February 2009 43 http://structuremap.sourceforge.net http://storyteller.tigris.org http://www.codebetter.com/blogs/jeremy.miller http://www.codebetter.com/blogs/jeremy.miller http://www.msdnmagazine.com

Table of Contents Feed for the Digital Edition of MSDN Magazine - February 2009

MSDN Magazine - February 2009 Contents Toolbox CLR Inside Out Data Points Cutting Edge Patterns In Practice Best Practices .Net Interop "Oslo" Basics Patterns Silverlight Under The Table Foundations Windows With C++ .NET Matters Going Places { End Bracket }

MSDN Magazine - February 2009

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.