ASP.NETRouting介绍

您觉得ASP.NET Routing中最令人摸不着头脑的设计是什么?我认为是RouteBase类:

专注于为中小企业提供网站设计制作、成都网站设计服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业平武免费做网站提供优质的服务。我们立足成都,凝聚了一批互联网行业人才,有力地推动了成百上千家企业的稳健成长,帮助中小企业通过网站建设实现规模扩充和转变。

 
 
 
  1. public abstract class RouteBase  
  2. {  
  3. protected RouteBase() { }  
  4. public abstract RouteData GetRouteData(HttpContextBase httpContext);  
  5. public abstract VirtualPathData GetVirtualPath(  
  6. RequestContext requestContext,  
  7. RouteValueDictionary values);  
  8. }  

它为什么是一个没有任何实现的抽象类,而不是一个接口(如下)?

 
 
 
  1. public interface IRoute  
  2. {  
  3. RouteData GetRouteData(HttpContextBase httpContext);  
  4. VirtualPathData GetVirtualPath(  
  5. RequestContext requestContext,  
  6. RouteValueDictionary values);  
  7. }  

这样做难道不更漂亮一些吗?这样代码中都可以使用IRoute类型,避免RouteBase这种令人反感的命名出现(个人感觉,不知道有没有同意的群众)。退一步说,命名上的“美感”是小事……但是抽象类在.NET平台中就产生了一个非常严重的限制:一个类无法继承多个基类。因此,在.NET平台上总是更倾向于使用接口,而不是抽象类。

但是接口里不可以有任何实现,那么可复用的功能又放在哪里比较合适呢?《Framework Design Guildlines》告诉我们:在一个类库中,***为接口定义一个默认实现,这样也是开发人员进行“扩展”的一个“参考”。也就是说,如果真有什么需要复用的实现,我们完全可以这么做:

 
 
 
  1. public abstract class RouteBase : IRoute  
  2. {   
  3. // reusable implementations  
  4. }  
  5.  
  6. public class Route : RouteBase  
  7. {  
  8. // concrete implementations  
  9. }  

事实上,.NET平台上有许多类库也遵循了这个做法。一个典型的做法便是ASP.NET AJAX框架的Extender模型:

 
 
 
  1. public interface IExtenderControl {   
  2. }  
  3.  
  4. public abstract class ExtenderControl : Control, IExtenderControl {   
  5. }  

甚至在ASP.NET AJAX Control Tookit项目中,还有更进一步的扩展:

 
 
 
  1. public abstract class ExtenderControlBase : ExtenderControl {   
  2. }  
  3.  
  4. public class AnimationExtenderControlBase : ExtenderControlBase {   
  5. }  
  6.  
  7. public class AutoCompleteExtender : AnimationExtenderControlBase {   
  8. }  

看来微软在项目团队内部推广《Framework Design Guidelines》还不够彻底。

在.NET平台下,一个没有任何实现的,纯粹的抽象类可谓有百害而无一利。我很怀疑写这段代码的人刚从C++切换到C#——但是ASP.NET Routing中其实也有接口(如IRouteConstraint),为什么作者自己没有意识到,也没有人提出不同意见呢?微软开发团队应该有着严格的Code Review过程,怎么会让这样的代码正式发布?要知道一个接口一旦公开,就不可以删除了。也就是说,微软很难弥补这个错误。

如果是方法名不好,或者职责有些不明确,这样还可以在旧方法上添加ObsoleteAttribute(这样编译器便会提示用户这个方法已经过期),并且将旧方法的调用委托给新的实现。例如:

 
 
 
  1. public abstract class CodeDomProvider : Component  
  2. {  
  3. [Obsolete(  
  4. "Callers should not use the ICodeCompiler interface and should  
  5. instead use the methods directly on the CodeDomProvider class.  
  6. Those inheriting from CodeDomProvider must still implement this  
  7. interface, and should exclude this warning or also obsolete this  
  8. method.")]  
  9. public abstract ICodeCompiler CreateCompiler();  
  10.  
  11. [Obsolete(  
  12. "Callers should not use the ICodeParser interface and should  
  13. instead use the methods directly on the CodeDomProvider class.  
  14. Those inheriting from CodeDomProvider must still implement this  
  15. interface, and should exclude this warning or also obsolete this  
  16. method.")]  
  17. public virtual ICodeParser CreateParser();  
  18.  
  19. ...  

可是,现在的问题是一个“类”,而这个类已经无处不在了,例如在RouteData中有一个属性Route,它便是RouteBase类型——如果将其修改为IRoute接口,那么至少也需要项目重新编译之后才能够“升级”。而作为一个公开类库,尤其是.NET这种成熟框架来说,应该做到“无痛”才对。

这次微软真搞笑了。以上介绍ASP.NET Routing。

原文出处博客园,作者赵劼

【编辑推荐】

  1. ASP.NET控件学习总结
  2. 有关ASP.NET MVC框架的一些基础知识
  3. 再谈ASP.NET缓存机制:开发效率与优化的平衡
  4. 如何避免ASP.NET缓存占用系统资源
  5. 点评一下ASP.NET的WEB控件

网站题目:ASP.NETRouting介绍
文章来源:http://www.shufengxianlan.com/qtweb/news35/485085.html

网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联