Analysis of the most confusing Design of ASP. NET Routing

 
 

  
  
public abstract class RouteBase  
  
  
{  
  
  
    protected RouteBase() { }  
  
  
    public abstract RouteData GetRouteData(HttpContextBase httpContext);  
  
  
    public abstract VirtualPathData GetVirtualPath(  
  
  
        RequestContext requestContext,  
  
  
        RouteValueDictionary values);  
  
  
} 
 
 

Why is it an abstract class without any implementation, rather than an interface as follows )?

 
 

  
  
public interface IRoute  
  
  
{  
  
  
    RouteData GetRouteData(HttpContextBase httpContext);  
  
  
    VirtualPathData GetVirtualPath(  
  
  
        RequestContext requestContext,  
  
  
        RouteValueDictionary values);  
  
  
} 
 
 

Isn't it more beautiful to do this? In this way, the IRoute type can be used in the code to avoid the unpleasant naming of RouteBase and people who do not know whether or not they agree ). To put it another step, the "beauty" in naming is a trivial matter ...... However, the abstract class has a very serious limitation in the. NET platform: A class cannot inherit multiple base classes. Therefore, the. NET platform is always more inclined to use interfaces than abstract classes.

However, there cannot be any implementation in the interface, so where is the reusable function suitable? Framework Design Guildlines tells us that in a class library, it is best to define a default implementation for the interface, which is also a "Reference" for developers to "scale ". That is to say, if there is anything that needs to be reused, we can do this:

 
 

  
  
public abstract class RouteBase : IRoute  
  
  
{   
  
  
    // reusable implementations  
  
  
}  
  
  
 
  
  
public class Route : RouteBase  
  
  
{  
  
  
    // concrete implementations  
  
  
} 
 
 

In fact, many class libraries on the. NET platform also follow this practice. A typical practice is the Extender model of the ASP. net ajax framework:

 
 

  
  
public interface IExtenderControl { }  
  
  
public abstract class ExtenderControl : Control, IExtenderControl { } 
 
 

Even in the ASP. net ajax Control Tookit project, there are further extensions:

 
 

  
  
public abstract class ExtenderControlBase : ExtenderControl { }  
  
  
public class AnimationExtenderControlBase : ExtenderControlBase { }  
  
  
public class AutoCompleteExtender : AnimationExtenderControlBase { } 
 
 

It seems that Microsoft's promotion of Framework Design Guidelines within the project team is not thorough enough.

On the. NET platform, a pure abstract class is not implemented. I suspect that the person who wrote this code has just switched from C ++ to C # -- but ASP. NET Routing also has an interface such as IRouteConstraint). Why didn't the author realize it and no one gave a different opinion? The Microsoft development team should have a strict Code Review process. How can such Code be officially released? You must know that once an interface is published, it cannot be deleted. That is to say, it is difficult for Microsoft to make up for this error.

If the method name is not good or the responsibilities are unclear, you can add ObsoleteAttribute to the old method so that the compiler will prompt that the method has expired ), and delegate the call of the old method to the new implementation. For example:

 
 

  
  
public abstract class CodeDomProvider : Component  
  
  
{  
  
  
    [Obsolete(  
  
  
        "Callers should not use the ICodeCompiler interface and should  
  
  
         instead use the methods directly on the CodeDomProvider class.  
  
  
         Those inheriting from CodeDomProvider must still implement this 
  
  
         interface, and should exclude this warning or also obsolete this 
  
  
         method.")]  
  
  
    public abstract ICodeCompiler CreateCompiler();  
  
  
 
  
  
    [Obsolete(  
  
  
        "Callers should not use the ICodeParser interface and should  
  
  
         instead use the methods directly on the CodeDomProvider class.  
  
  
         Those inheriting from CodeDomProvider must still implement this 
  
  
         interface, and should exclude this warning or also obsolete this 
  
  
         method.")]  
  
  
    public virtual ICodeParser CreateParser();  
  
  
 
  
  
    ...  
  
  
} 
 
 

However, the current problem is a "class", and this class is everywhere. For example, in RouteData, there is an attribute Route, which is the RouteBase type-if you change it to the IRoute interface, at least the project must be re-compiled before it can be "upgraded ". As a public class library, especially a mature framework such as. NET, it should be "Painless.

This article is from Zhao's blog garden Article ASP. NET Routing, the most confusing design.

1. ASP. NET Control Learning Summary
2. Some basic knowledge about ASP. net mvc Framework
3. ASP. NET cache mechanism: balance between development efficiency and Optimization
4. How to Avoid ASP. NET cache occupying system resources
5. Comments on ASP. net web controls