Type safe route registration in ASP.NET MVC

October 18, 2009 17:25

A few days ago my workmate Ian made a point that there should be a nice way to implement type safe route registration in ASP.NET MVC.

Type safe! Can anyone read these words without experiencing a tug of excitement, without being swayed by the view of departed bugs and newly arrived refactorings on controllers and actions - refactorings that don't break your app?

Indeed, type safe is possible. Here's how we register our routes now:

routes.MapRoute(
    "viewProduct",                                                        
    "{locale}/{product}/view/{mode}/",                                 
    new { controller = "Product", action = "Display", mode = "full" }  
);
 
and here's a type safe way:

routes.MapRoute(
    "{locale}/{product}/view/{mode}/")
     .On<ProductController>(x => x.Display("full"));

More...

The Law of Demeter, The crux of

June 21, 2009 20:12
var zipCode = order.Customer.Address.ZipCode;

Have something like that in your code? Suprise, surpsire - this is called "train wreck" coding style. To get the zip, we should know (and rely on) the whole chain of components. An unrelated change somewhere else in the system can break the line above.

To get rid of such chains, we should recall The Law of Demeter and, generally, the notion of "shy" code. Shy is two-fold:
  • don't reveal too much of yourself to others. Do not mark things public if they can be private (or internal, etc), avoid putting several methods of a similar purpose on your public API, avoid global data (and avoid singletons - if feasible - because they are global).   
  • don't interact with others more than it's necessary. Basically, call as few methods as possible. Methods with smaller response set (response set is a number of functions/properties called by a method) are less prone to error and break less frequently, as they're less coupled with the rest of the system. 

More...


Darwinism Driven Development

January 25, 2009 20:13

Most of us would agree with Christopher Alexander, that the central task of architecture is creation of a single, shared, evolving pattern language. And pattern language does not necessarily mean a suite of general ideas.

It can be any
thing: a development framework, or a set of APIs, or a pool of reusable artifacts. In either case, clarity and usability is that what matters. Hey, it's a pure darwinism: struggle for existence and natural selection. The more people choose the artifacts you create, the better those artifacts spread, and the longer they stay.

That's why one of the most significant jobs of an architect is to create appealing artifacts. Those that developers will use correctly and will want to reuse. Those that are easy to understand, adapt, evolve, and explain to others.


Commenting code. Part 2

November 16, 2008 20:50

Let's look at the following piece of .ascx.cs code [1]:

///<summary>
/// 0 - parentId,
/// 1 – postbackUrl,
/// 2 – container,
/// 3 – default uploader
///</summary>
private const string template = @"{0} = new Uploader ('{0}','{1}','{2}','{3}');";
 
...
string script = string.Format(template, ClientID, ...);
AddJavascript(script);
 
It’s one of those web development oldies: combine some parameters on the server side and a javascript object gets created in a browser.  The problem is that if you need to pass more than 2-3 parameters the code becomes less clean. It gets difficult to tell what every single parameter means on the javascript side of things. That’s why the author needed a comment in the first place.
More...