ASP.NET 4.0 来了
伴随着VS2010的公开测试,ASP.NET4.0也进入了我们的视线。ASP.NET4.0究竟给我们带来了什么,将在哪些方面提高我们的生产力?
在何时你需要使用ASP.NET4.0开发你的网站程序?
- 需要更严格的遵守Web标准;
- 需要更流畅的Web Form开发方式;
- 需要更好的搜索引擎优化;
- 需要后知后觉的纠正一些不够优良的设计,这些设计甚至可能是在ASP.NET 1.0发布之前就存在的;
- 需要将现有的功能重新改造为支持server farm或跨application domains;
- 需要将.NET调节和重组为一个整体。
你不需要学习复杂的设计模式或各种SEO技巧,甚至不需要有代码重构的能力。忘记那些复杂的规定和教条吧,使用ASP.NET4.0提供的各种方便又实用的新功能,你将能轻松的开发/升级出与时俱进的高质量的程序。而这一切均需要从这里开始:
-
下载,安装VS2010
- http://www.microsoft.com/visualstudio/zh-cn/products/2010/default.mspx#compare
- 安装之前务必卸载之前的测试版本,包括.NET Framework 4。新版本的VS2010包含了大量更新,与之前的测试版本并不兼容 。
-
新的预定义界面:
VS2010带来了一个新的预定义设置:Web Development(Code Only),如字面所示,它是为了web开发而设计的,但与普通的Web Development模式不同的是,它针对的是喜欢手写代码的开发人员,它让VS看起来更像一个单纯的IDE:
至于您是否喜欢,就萝卜青菜,各有所爱了。。。(我还是喜欢全屏模式。。)
-
新的项目类型:
VS2010对ASP.NET的项目类型做了大量的更改,具体改动如下:
- ASP.NET Web Service Application被完全的移除了;
- .Net3.0 带来的 WCF Service Application 移至 WCF projects 下;
- .Net3.5 SP1 带来的两个 Dynamic Data 相关的项目被改为更容易理解的名称,例如 Dynamic Data Web Application 使用LINQ to SQL替换了之前的Entity Framework;
- MVC项目有了一个称为 ASP.NET MVC2 Empty Web Application 的新选择。新的 ASP.NET MVC2 Empty Web Application 项目会建立如下的内容:标准的目录(空),空白的global.asax文件,web.config文件,标准的jQuery和MS AJAX库。相比较而言,ASP.NET MVC2 Web Application项目会生成一个可工作的网站,实现一个简单的membership模型,生成并使用master page,error page及所需的content page,并且可以生成一个示例test project。这对MVC新手非常有帮助,可以较为全面的使用MVC的功能。
-
简洁的Web.Config文件
在VS2008SP1中,默认的web.config文件代码有139行,而在ASP.NET4.0中,web.config 文件只有6行:
原理很简单,ASP.NET团队对web.config文件进行了重构,将通用的设置写进默认的机器级别的web.config中。只剩下两个需要频繁变化的设置项。
- debug的值在Web Application 项目中会被默认设置为true,在Web Site 项目中会被默认设置为false。
- targetFramework的值可以设置为:4.0,3.5,3.0和2.0。这个选项会被IIS识别并自动赋予ASP.NET程序池相应的Framework版本。
- Intellisense在旧版的web.config中会不起作用。可以通过删除原web.config中configuration的namespace(xmlns)属性就可以了。
*.config文件的层级结构:
在新的config文件定义中,一系列功能例如:Dynamic Data,routing与charting全部默认开启。
关于不同级别的config文件的关系,非常类似与CSS文件的复写。简单的来说就是离你越近的config权值越高,也就是最底层的machine.config权值最低,你新建的web项目中的web.config的权值最高。
- root的config文件为machine.config,位于C:\Windows\Microsoft.NET\Framework\ v4.0.xyz\Config。
- 机器级别的web.config文件同样位于上面的那个目录,它在machine.config文件的基础上定义了web特定的一些节点的默认值,也就是在之前的ASP.NET版本中创建项目生成的web.config的文件中的那些值。
- 同样在上面那个目录中,你会发现如下的文件:web_hightrust.config, web_mediumtrust.config, web_lowtrust.config 和 web_minimaltrust.config。如果你的站点的信任级别不是“FULL”,将会使用对应的config文件作为默认值。
- 在你创建的项目中,会默认生成一个web.config文件,这也是我们通常所说的web.config文件。
- 在你的项目的任何目录中,你都可以添加一个web.config文件,这个文件中的值会覆盖项目根目录中的值。你可以利用这个特性做一些例如权限限制之类的功能。
-
Config Transformation Files
这个新功能是为了应对同一个网站在不同服务器需要不同的web.config文件的问题,例如需要不同的connectionstring等。在以前我们可能很难维护这些不同的web.config文件(在我经历的项目中,为了解决这个问题,使用了com组建读取注册表,在不同机器的注册表中写入相应的信息),而现在有了这个新功能,我们可以以编程的方式统一的解决和处理这个问题(基于XPATH技术)。你只需要在web.config文件上右键单击,并选择“Add Config Transforms”即可。
-
Browscap.ini
对于使用过ASP的程序员来说,应该对这个文件并不陌生。这个文件是用来记录所有要使用的浏览器,以及这些浏览器所支持的特性(例如是否支持activeX)。
在.NET2.0中,微软将browsercap.ini的功能分割为一系列的*.browser文件。当收到一个请求的时候,我们就可以根据这个请求发起的browser找到对应的browser文件来获取浏览器的能力。这些数据会被传递到HttpBrowserCapabilities对象中,我们就可以使用这些数据了。
所有的browser文件可以在C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers下被找到。里面其实还是挺齐全的。
将一个文件分割成一系列文件会造成更加难以维护的情况,但这么做的理由似乎也不难猜想,就是微软希望一系列的浏览器使用同一个文件,例如ie.browser, mozilla.browser之类的。
在.NET4.0中,微软继续沿袭了这一思路,并且大范围的更新了这些文件,以支持现在流行的浏览器,特别是移动浏览器:iPhones, Windows PhoneOS, Android等,并且不会把这些浏览器简单的处理成wap浏览器。对于桌面浏览器来讲,也添加了对Firefox,Chrome和Safari的支持。
这么做很好,但是问题来了,难道我们要等每个新的.Net Framework发布后才能获得这些新的文件吗?答案当然是否定的。
如今浏览器发展日新月异,马上又即将有IE9, Opera 10.5, Gecko 1.9.3和新的IE for mobilephone等等。如果我们希望支持这些新的浏览器,我们有四种选择:
- 手动更新这些browser文件或者创建新的browser文件。
- 创建一个新的browser文件并将它添加在你的站点的App_Browser文件夹下。但这样只对你当前的站点有效。
- 扩展现有的browser capabilities provider。
- 创建一个自定义的browser capabilities provider替换现有的。
你可以针对你所拥有的资源或网站架构来选择如何解决这个问题。我们推荐使用自定义的browser capabilities provider去解决,虽然需要更多代码,但一旦完成,之后的更新将会更轻松。这就意味着你能更迅速的支持新的浏览器。
但无论如何,支持一个新的浏览器都是一个困难的工作,但.NET4.0给我们带来的最新的browser支持文件和一个可扩展的方法。
-
新的Page属性
任何ASP.NET开发人员对于@Page标签都不会陌生。好消息是ASP.NET4.0完全兼容之前版本所提供的42个属性。更好的消息是,ASP.NET4.0还带来了6个新的属性,以应对日益复杂的开发需求:
- ClientIDMode 顾名思义,这个属性用来定义ASP.NET将如何生成控件的客户端ID,如果你是一个前端开发人员,你将会明白能够确定的控制客户端ID的生成将带来多大的便利。可能的值为AutoID(default/current),Predictable,Static和Inherit。
- ClientTarget 用来定义页面将针对哪个浏览器来执行。这将覆盖ASP.NET提供的自动浏览器识别功能,可能的应用场景为比如我们只需要支持IE浏览器或只需要支持FIREFOX等。
- MetaDescription 顾名思义,用来生成页面的meta 的description标签。在我看来只是提供了一个更为官方的方法和方式,标准化了这一流程。
- MetaKeywords 顾名思义,用来生成meta的keywords标签。
- TargetSchema 用来定义验证页面所需的schema。这个标签只是用来标识的,并不会真正的执行。可以看作一种代码注释。
- ViewStateMode 用来定义页面的VIEWSTATE是opt-in还是opt-out(默认)模式。
总体来说变化不大,提供了一些呼声很高的功能。
-
生成更纯净,更标准的HTML代码
这一直是ASP.NET中比较大的问题。ASP.NET1.1生成的html代码基本都不符合标准,这一点在ASP.NET 2.0中已经进行了改进,我们在web.config中引入了xhtmlConformance,用来定义控件将生成何种标准的HTML代码,默认为XHTML1.0 Transitional standard(Transitional)。相应的,我们可以将它设定为XHTML1.0 Strict(Strict)或者选择生成与ASP.NET1.1相同的HTML代码(Legacy,主要用来兼容从ASP.NET1.1升级而来的网站)。
不幸的是,在Legacy模式运行的网站与ASP.NET AJAX不兼容,而且尽管Transitional与Strict模式与XHTML标准兼容,但生成的代码对CSS也是非常不友好的。例如:
- menu用table输出而不是UL/OL。
- 服务器端的控件属性例如 border=0 或disabled=disabled 是强制的并且无法移除。
- 对于支持template的控件,你可以对template内的代码进行任何的自定义,但无法移除最外层的table标签。
ASP.NET3.5带来的ListView,DataPager和CSS Control Adapters控件带来了过渡性的解决方案,ASP.NET4.0完全将他们集成在新版本的System.Web中,使得微软可以使ASP.NET 4.0可以尽可能的对CSS友好。毋庸置疑,生成干净的HTML标签是ASP.NET 4.0的重要目标之一。
- ControlRenderingCompatibilityVersion
与xhltmlComformance类似,ASP.NET4.0为web.config带来了这个新的属性。当设置为3.5时,一切将和原来一致,但当你设置为4.0时,控件将按照全新的模式输出HTML代码:
- xhtmlConformance被设置为Strict。
- menu将会用UL/OL的形式输出。
- 多余的HTML属性将被移除,甚至连validation的字体颜色也不会被设置为红色。
- 将可以对控件使用RenderOuterTable属性来控制是否输出外围的table标签。
在我看来这对于习惯使用控件的同学是个好消息。微软又帮你做了许多工作。
-
新增的一些小功能
列举一些新增的细节功能
- 内置<asp:chart>。
- 三种新的Redirect方式:Response.RedirectToRoute(HTTP302), Response.RedirectToRoutePermanent(HTTP301)和Response.RedirectPermanent(HTTP301)。
- Inline的HTML encoded 字符串。
- Routing配置更便捷。
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。