Go homepage(回首页) Upload pictures (上传图片) Write articles (发文字帖)
The author:(作者)delvpublished in(发表于) 2014/1/6 9:02:00 ASP.NET2.0的新增服务、控件与功能_[Asp.Net教程]
单个子页面享有重写默认母版页和指定它们自己的母版页的自由。 最精彩的部分是Visual Studio 2005中对母版页的支持。当加载子页面时,IDE将显示母版页中定义的内容的灰色、只读版本,以及子页面中定义的内容的全色、完全可编辑版本。区分这两者很容易,并且如果要编辑属于母版页的内容,那么您需要做的全部事情只是在IDE中打开母版页。 有关母版页的更多深入内容,请参阅相关的文章。
数据源控件 数据绑定在ASP.NET 1.x中占据着显著位置。几行位置恰当的数据绑定代码可以取代大量查询数据库,并使用对Response.Write方法的重复调用,从而将查询结果转换为HTML内容的ASP代码。 下面的DataSource1.aspx页使用ASP.NET 2.0数据绑定来显示SQL Server Pubs数据库的一部分:
<%# DataBinder.Eval (Container.DataItem, "title") %>
<%# Eval("title") %>
<%@ Page Theme="ShockingPink" %>
新增控件 ASP.NET 2.0将引入大约50种新的控件类型,以便帮助您生成丰富的用户界面,同时使您无须应付HTML、客户端脚本和浏览器文档对象模型(DOM)的各种变幻莫测的行为。“新增控件”提要栏列出了直至本文撰写时规划的新控件(Web部件控件除外)。 DynamicImage控件简化了在Web页中显示动态生成的图像的任务。在过去,开发人员经常编写自定义HTTP处理程序来处理动态图像生成,甚至更糟糕的是,处理ASPX文件中生成的图像。DynamicImage使得这两种技术都过时了。代码4 中的代码使用DynamicImage控件来绘制饼图。关键语句是那个将图像位分配给控件的ImageBytes数组的语句。 DynamicImage控件利用了新增的ASP.NET 2.0图像生成服务。另一种访问图像生成服务的方法是,在ASP.NET 2.0的全新ASIX文件中动态生成图像。本文随附的示例文件(可从MSDN Magazine Web站点上获得)包含一个名为DynamicImage.asix的文件,它展示了ASIX文件的要素。要运行该文件,请将DynamicImage.asix复制到Web服务器的某个虚拟目录中,然后在浏览器中激活该文件。
ASP.NET 2.0中首次亮相的另一个有趣且非常有用的控件是MultiView控件。与View控件搭配使用时,MultiView可用来创建包含多个逻辑视图的页面。一次只能显示一个视图(其索引被分配给MultiView的ActiveViewIndex属性的那个视图),但您可以通过更改活动视图索引来切换视图。对于使用选项卡或其他控件来让用户在逻辑页之间进行导航的页面而言,MultiViews是非常理想的。 代码5 中的页面使用一个MultiView来显示Pubs数据库Titles表的两个不同视图:其中一个用GridView呈现,另一个用DetailsView呈现。视图切换是通过从下拉列表中进行选择来完成的。请注意,标记中的AllowPaging属性使用户可以浏览DetailsView中的记录。
GridView和DetailsView控件 DataGrid是ASP.NET中最受欢迎的控件之一,但在某些方面,它也成为自己成功的牺牲品:如此丰富的功能,以至于让ASP.NET开发人员不满足于此,而是希望它能提供更多功能。DataGrid控件在ASP.NET 2.0中并没有发生太大变化,只是添加了两个分别名为GridView和DetailsView的新控件,它们提供了通常要求DataGrid控件所具有的功能,并且还加入了一些属于它们自己的新功能。 GridView呈现HTML表的方式与DataGrid一样,但与DataGrid不同的是,GridView可以完全依靠自己来分页和排序。GridView还支持比DataGrid种类更为丰富的列类型(在GridView用语中称为字段类型),并且它们具有更为智能的默认呈现行为,能够自动呈现Boolean值(例如,通过复选框)。GridView也可以容易地与DetailsView搭配使用,以创建主-从视图。GridView控件的主要缺陷是:像DataGrid一样,它通过将信息传回到服务器来完成它该做的大部分工作。 代码6 中的页面结合使用了GridView和DetailsView,以创建Pubs数据库的Titles表的简单主-从视图。SqlDataSource控件为其他控件提供数据,而绑定到DetailsView控件的SqlDataSource中的SelectParameter使DetailsView能够显示GridView中当前选择的记录。可以通过单击GridView的Select按钮(该按钮因标记中的AutoGenerateSelectButton="true"属性而存在)来选择记录。
请注意GridView和DetailsView控件中用于定义字段类型的和元素。这些元素实际上等效于DataGrid控件中的元素。表1列出了受支持的字段类型。特别重要的是ImageField和DropDownListField,它们都可以有效地削减目前开发人员为在DataGrid中包含图像和数据绑定下拉列表而编写的大部分代码。
表1 GridView and DetailsView字段类型
新增的管理功能 ASP.NET 1.x的另一个明显的缺陷(已经在ASP.NET 2.0中得到修复)是根本没有用于管理Web站点的接口(无论是声明性接口还是编程接口)。在过去,更改配置设置意味着启动记事本并编辑Machine.config或Web.config,但现在不再需要这么做了。ASP.NET 2.0具有一个完善的管理API,它简化了读取和写入配置设置的任务。它还包括一个管理GUI,您可以通过在浏览器中请求Webadmin.axd来显示该GUI,如图8所示。
图2 管理GUI
尽管在撰写本文时尚不完善,但Webadmin.axd被设计为使您可以配置ASP.NET 2.0中包含的各种服务(如成员身份和角色管理服务)、查看Web站点统计信息以及应用安全设置。 成员身份服务 ASP.NET 2.0中新增的最佳功能之一是新的成员身份服务,它提供了用于创建和管理用户帐户的易于使用的API。ASP.NET 1.x大规模引入了窗体身份验证,但仍然要求您编写相当数量的代码来执行实际操作中的窗体身份验证。成员身份服务填补了ASP.NET 1.x窗体身份验证服务的不足,并且使实现窗体身份验证变得比以前简单得多。 成员身份API通过两个新的类公开:Membership和MembershipUser。前者包含了用于创建用户、验证用户以及完成其他工作的静态方法。MembershipUser代表单个用户,它包含了用于检索和更改密码、获取上次登录日期以及完成类似工作的方法和属性。例如,下面的语句采用用户名和密码作为参数,并返回true或false来指示它们是否有效。它取代了对ASP.NET 1.x应用程序中、使用Active Directory?或后端数据库来验证凭据的简易方法的调用,如下所示:
角色管理器 如果不支持基于角色的安全性,那么成员身份服务和登录控件将是不完善的。在ASP.NET 1.x中,要将窗体身份验证与角色结合起来,需要编写代码以将角色信息映射到各个传入的请求。ASP.NET 2.0中新的角色管理器(它可以与成员身份服务配合使用,也可以不与其配合使用)取消了对此类代码的需求,并且简化了基于角色授予用户访问各种资源权限的任务。 角色管理是基于提供程序的,它通过Web.config启用。角色管理器通过新的Roles类来公开API,该类公开了名为CreateRole、DeleteRole和AddUserToRole等的方法。值得注意的是,您或许永远不需要调用这些方法,因为Webadmin.axd完全能够创建角色、将用户分配给角色以及完成其他任务。一旦启用,基于角色的安全性就能够使用所提供的角色信息以及Web.config文件中的URL身份验证指令来工作—这与ASP.NET 1.x中您已经熟悉的URL身份验证相同。 既然您已经熟悉了成员身份服务、登录控件以及ASP.NET角色管理器,那么您或许希望看到同时使用这三者的示例。本文可下载的代码示例包含一个两页的应用程序,它演示了Visual Studio 2005样式的窗体身份验证。要部署该应用程序并对其进行测试,请首先将PublicPage.aspx、LoginPage.aspx和Web.config复制到Web服务器的某个虚拟目录中。在该虚拟目录中创建一个名为Secure的子目录,然后将ProtectedPage.aspx和其他Web.config文件复制到该子目录中。 启动Webadmin.axd,并且将站点配置为使用窗体身份验证,将成员身份和角色服务配置为使用您选择的提供程序。同时,还要创建名为Bob和Alice的用户以及名为Manager和Developer的角色。将Bob指定为Manager角色,将Alice指定为Developer角色。(我不会列出所有步骤,因为在您使用任一方法阅读本文之前,它们很可能会改变。幸运的是,Webadmin.axd相当直观,并且它具有向导,可以引导您完成设置过程。) 接下来,在浏览器中激活PublicPage.aspx,并单击“View Secret Message”按钮以查看ProtectedPage.aspx。ASP.NET会将您重定向到LoginPage.aspx,该页面使用Login控件来请求用户名和密码。使用Bob的用户名和密码登录。ProtectedPage.aspx应该显示在浏览器窗口中,因为Bob是Manager,并且可以通过Secure目录中的Web.config文件将访问权授予经理。请注意LoginName控件显示的用户名以及LoginStatus控件显示的“Log out”链接。最后,关闭浏览器,然后重新打开它并重新激活PublicPage.aspx。单击“View Secret Message”并以Alice的身份登录。这一次,您将无法到达ProtectedPage.aspx,因为Alice不是经理。 我使用了一个类似的应用程序来讲述ASP.NET 1.x中的窗体身份验证,但1.x版本要求编写非常多的代码。2.0版本因其简洁而不同寻常,尤其是没有任何用于验证在登录窗体中键入的凭据、或者将用户名映射到角色的代码。如果您仍然不相信,请尝试用ASP.NET 1.x实现同一应用程序!此外,请确保检验Webadmin.axd对Web.config所作的更改。除了其他内容以外,您还应该看到一个启用角色Manager并且可能会指定角色管理提供程序的元素。 您可能很想知道角色Manager是否经过了到数据库(在其中,角色被存储到每个请求中)的往返行程。值得庆幸的是,答案是“否”。它将角色编码到Cookie中,并且为了保密而将它们加密。如果一个用户对应了众多的角色(这种情况不太可能发生),以至于无法将这些角色编码到一个Cookie中,则该Cookie将包含一个最近使用角色的列表,并且仅在迫不得已时才查询数据库。 个性化 另一个新增的服务是个性化,它提供了一种现成的解决方案,用于解决存储站点用户的个性化设置问题。目前,此类设置通常存储在Cookie、后端数据库或这两者中。无论这些设置存储在何处,ASP.NET 1.x都不能提供什么帮助。这需要由您来设置和管理后端数据存储,以及使用经过身份验证的用户名、Cookie或其他某种机制来关联个性化数据。 ASP.NET 2.0个性化服务使得存储各个用户的设置以及随意检索这些设置变得非常容易。该服务基于用户配置文件—您可以使用新的元素在Web.config中予以定义。下面的代码节选自Web.config:
<name="Theme" allowAnonymous="true" />
新的动态编译模型 ASP.NET 1.x中引入的众多创新之一是:系统能够在首次访问您的代码时对其进行编译。但是,只有页面能够被自动编译,并且辅助类(如数据访问组件)必须单独编译。 ASP.NET 2.0扩展了动态编译模型,以便能够自动编译几乎所有的组件。bin目录仍然保留以便实现向后兼容性,但它现在添加了名为Code和Resources的目录。Code目录中的C#和Visual Basic文件以及Resources目录中的RESX和RESOURCE文件被ASP.NET自动编译并缓存在系统子目录中。此外,落入Code目录中的Web服务描述语言(WSDL)文件被编译为Web服务代理,而XML架构定义语言(XSD)文件被编译为类型化数据集。通过Web.config,还可以扩展这些目录以支持其他文件类型。 预编译并且在不带源代码的情况下进行部署 提到动态编译,与ASP.NET 1.x有关的最常见问题之一是:是否可以预编译页面,以避免在首次访问页面时发生的编译延迟?尽管该问题本身在某种程度上无关紧要(延迟非常小,并且延迟的开销被成千上万甚至数以百万的后续请求所分摊),但Microsoft仍然感到有必要采取相应的措施来减轻开发人员的担忧。这一“措施”就是能够通过提交对名为precompile.axd的幻像资源的请求,来预编译应用程序中的所有页面。 但预编译并不仅限于此。另一个经常被请求的功能是:能够将整个应用程序预编译为可以在不带源代码的情况下进行部署的托管程序集(该功能在宿主方案中尤其有用)。ASP.NET 2.0包含一个名为Aspnet_compiler.exe的新的命令行工具,它能够执行预编译并且在不带源代码的情况下进行部署;Visual Studio 2005将包含类似的功能。下面的命令将预编译Web1目录中的应用程序,并且在不带源代码的情况下将其部署到Web2:Aspnet_compiler -v /web1 -p c:\web1 c:\web2 之后,目标目录将包含空的ASP.NET文件(ASPX、ASCX、ASIX等等)以及源目录中存在的所有静态内容(如HTML文件、.config文件和图像文件)的副本。在不带源代码的情况下进行部署并不会为您的知识产权提供牢不可破的保护,因为聪明的ISP仍然可以通过反编译生成的程序集来弄清楚应用程序的来龙去脉,但是,它确实对一般的代码窃取者设置了更大的阻碍。 新的代码分隔模型 ASP.NET 1.x支持两种编程模型:内联模型—HTML和代码共存于同一个ASPX文件中;代码隐藏模型—它将HTML分隔到ASPX文件中,并将代码分隔到源代码文件(例如,C#文件)中。ASP.NET 2.0引入了第三个模型:一种新的代码隐藏形式,它依赖于Visual C#和Visual Basic .NET编译器中的不完全类支持。新的代码隐藏解决了原来的代码隐藏中存在的一个恼人的问题:传统的代码隐藏类必须包含受保护的字段,这些字段的类型和名称需要映射到ASPX文件中声明的相应控件。 代码7 显示了新的代码隐藏模型的工作方式。Hello.aspx包含页面的声明部分,Hello.aspx.cs包含代码。您应该注意@ Page指令中的CompileWith属性。此外,请注意MyPage类中缺少的字段(它们提供到ASPX文件中声明的控件的映射)。旧样式的代码隐藏仍然受支持,但新样式将是今后的首选编程模型。一点都不奇怪,Visual Studio 2005天生就支持新的代码分隔模型。
验证组 验证控件是ASP.NET 1.x中更为卓越的创新。诸如RequiredFieldValidator和RegularExpressionValidator之类的控件使开发人员能够在客户端和服务器上进行更为智能的输入验证,而不必成为客户端脚本编写和浏览器DOM方面的专家。遗憾的是,版本1.x验证控件存在一个致命的缺陷,即:没有一种比较好的方法来将这些控件组合在一起,以便页面的一个部分上的验证程序可以重写该页面其他部分上的验证程序,并且无论其他验证程序的状态如何,都可以使回发发生。 该问题由ValidationGroups1.aspx阐明,它包含在您可以针对本文下载的示例中。页面的设计者预计用户能够填写一组TextBox并回发到服务器,而不必同时填写另一个组,但它并不按此方式工作。除非所有输入字段都被填充,否则验证程序将抱怨不休,如图12所示。图4 ASP.NET 1.x中的验证控件 ASP.NET 2.0中的新验证组功能一劳永逸地解决了该问题。现在,可以使用ValidationGroup属性来组合验证控件。可以用相同的方式将按钮控件分配给组,并且当一个组中的所有验证程序都对输入感到满意时,它们才允许回发发生,当然,前提是回发是由验证程序同一组中的控件生成的。ValidationGroups2.aspx演示了该技术(参见代码9)。从表面上看,该页面与ValidationGroups1.aspx完全相同。但在内部,它们却完全不同。现在,您可以填写任一组TextBox,并且通过单击TextBox验证组中的按钮进行回发。
赞