一、Data Source Controls
SqlDataSource：儿童玩具型数据源，它就像你平常做的数据访问类一样，不过只需要设置它的一些属性就可以工作了，并且它和其它的数据显示控件很好的合作。因此还是很方便的。如果有了VS还不懂用这个玩意儿，那么可以直接去幼儿园进修了。
ObjectDataSource：企业级解决方案，不用再为UI层烦恼了，如果你做基于数据库的应用。可以轻松地把您的数据访问层或者业务层绑定在这个可爱的东西上面了。它用起来就像上面的儿童玩具一样的方便。真是玛丽顾得啊。
还有XmlDataSource和SiteMapDataSource来绑定于XML文件或站点地图（后面会提到，默认也是XML格式的），还可以使用XPath从中选择，或者直接使用XSLT转换XML（XmlDataSource）
忘记了还有另一个儿童玩具AcceseDataSource。不要小看儿童玩具哦，多啦A梦...
二、New Data Bound Controls
GridView：新的表格型数据控件，用来取代DataGrid。实际上，在VS2005中的工具栏上已经默认没有DataGrid了，可能是无地自容了。简单的说，GridView就是一个傻瓜式的DataGrid，不必再为一个简单的分页或者其它的什么功能写一大堆代码了。一个属性就摆平了。并且它的列更加丰富。为了区分DataGrid的Column属性，它的列都叫Field了，真不知道万一还有新的需要，3.0中会叫什么？
DetailsView：如果做一个数据表的维护，那么就会有这样的东西，无聊地编写增加和个性的页面，并且写一大堆更无聊的代码。那么现在DetailsView就是其中的一个不错的解决方案了。终于解放了啊。DetailsView就是一条记录的数据控件，可以增加和修改，还可以翻页。
FormView：可以把它当作DetailsView的自定义版本了，在下面的绑定中介绍。
三、Data Controls Parameter
就是上面那些Data Source的参数，有多种，就不一一解释了，仅将其列出。其中如果Data Source和Data Bound Controls共同使用时，参数名是有限制的。Parameter（静态）；QueryStringParameter；ControlParameter；SessionParameter；FormParameter；CookieParameter；ProfileParameter。
四、Improved Data Binding Syntax
新的绑定方法<%# Eval(...) %>和<%# Bind(...) %>，不需要再有Container.DataItem了，因为这两种方式只能用在数据绑定的容器内。其中Bind为双向绑定，可以从数据源Data Source绑定到Data Bound Control，而可以从数据显示控件返回到数据源控件。
五、竖向控件
即新的控件TreeView和Menu，Menu就像微软网站上的那个菜单，TreeView就是MSDN的那种树状方式，而实际上TreeView也可以实现像MSDN一样的分块读入，但是没有实际测试，不知道能不能适用于各个浏览器，不过TreeView再不是原先1.1时微软提供的那个劣质品了。
2.0的数据绑定完全改变了方式，当然，它还是向下兼容的，不过我想新的方式可能确实会给我们带来相当的便利
在N久之前，还在CSDN上论坛上看到过这样的说法：ASP.NET的客户端验证不安全。然而实际上验证控件是在服务器端验证的，不管客户端是否发生了验证。而像Firefox这样的浏览器更是所有的验证都是在服务器上执行的。
因为1.x版本的验证控件是用HTML自定义属性来实现的，而除IE及IE内核的浏览器外，这些特性是不被支持的，因此，在验证其它浏览器的数据时无论如何都只能返回服务器了。在2.0中，这个特性终于被修改了，虽然看起来有点傻傻的。是的，它确实像我们普通会javascript的人都会想到的一样，使用javascript为验证控件生成的span元素增加属性。但是，这么简单的改动却使得可以使用客户端验证的浏览器大大增加了（基本上都可以了）。
而通过Page的属性ClientTarget可以设置所有的验证控件是否会在客户端验证。只要将这个属性设置为UpLevel就可以了，DownLevel下，所有的验证都只会在服务器上执行了。默认情况下，大多数浏览器都是会在客户端验证的，所以我并不知道它的这个属性是不是默认UpLevel了。当然，如果要为单独的一个或几个验证控件设置的话，那么还是使用原先的EnableClientScript。
另外还增加了一个SetFoucsOnError属性。就是当出错的时候将焦点移到控件上。这样就不会使用户在点击了按钮之后因为没看到错误提示而在那发愣了。另外一个小东西就是CustomValidator增加了ValidateEmptyText属性来让用户自定义验证控件在值为空时也验证。
下一个有用的特性是ValidationGroup属性，将你在一个按钮点击时要验证的控件设置为同一个组名吧，而另一个按钮要验证的设置为另一个名，这样就可以使点击一个按键时只发生期望的验证，而不是所有的验证，而不必在服务器端显示来控件。注意，按钮也应该设计ValidationGroup属性。
最后一个就是比较验证控件将使用与文化无关的格式。
验证控件的改变从使用上来说没有多少改变。
Window XP的样式终于被可爱的M$搬到ASP.NET中了。这样的东西让我想到了M$的恐怖的想法，原先150智商现在被分解了，150智商=微软解决方案+50智商+已经学会了容忍不完美和失误。当然，如果您的智商已经是150的LEVEL，那么使用微软解决方案可能会导致溢出。（不在讨论范围之内）
其实用样式和主题这样的词并不能很好的说明ASP.NET 2.0中出现的这些东西。因为它很容易和我们的网页样式表css混淆起来。实际上，可以在主题和皮肤中可以定义的绝不仅仅是CSS样式而已。QuickStart中称之为服务器的端的样式，这样会更合适一点。在主题和皮肤中，绝大部分的内容都是可以使用定义的，当然不包括Id。
所有的主题和皮肤都必须放在一个叫App_Themes的目录下，这个目录可以是应用程序级的（把它放在你的站点目录下）或者是全局的（放在.net的目录下，或者放在IIS的一个目录下，具体参见帮助）。主题实际上就是多个皮肤的集合，在App_Themes下的子目录名就是主题名。而主题名下的后缀名为.skin的文件就是皮肤文件。
皮肤文件的写法更是傻瓜式的，其实就是把原先写在控件下的属性移至.skin下。写法和.htmlx文件基本上是一样的，只不过没有Id属性，却多了一个SkinId的属性。不用怀疑，在页面中使用同样的SkinId就可以使用这个皮肤定义的样式了。而在皮肤文件中没有使用SkinId属性的控件，将是默认应用到页面中所有没有指定SkinId的同类控件上。
不好意思，忘记了说在Page指令或者程序代码中要显示指定Theme属性，属性的取值就是App_Themes下子文件夹的名字。另外还有一个StyleSheetTheme属性，也是同样的取值范围。晕乎哉？传说Theme属性>页面中指定的属性>StyleSheetTheme属性中指定的属性。但是例子中上述说法很明显是成立的。
不知道大叔大婶姐姐哥哥们有没有考虑过，在一个站点中出现N次男、女这类的下拉框时该怎么办？在每个页面写它的ListItem吗？绑定数据库或XML？漫漫的人生就在这样的思考中消失？如果是这样的话，那么你应该开始喜欢上皮肤了，您可以把你的简单的数据选择框的内容放到皮肤文件里去了。
在皮肤文件中甚至可以出现数据绑定表达式！当然这个是很有限的，仅在数据显示控件，如DataList，DataGrid，Repeater，GridView等（VS2005工具栏中它们被放置在一个单独的组里）。并且必须使用新的Eval或Bind表达式，并且不能在皮肤里执行绑定。
在皮肤文件中也可以使用CSS或者图片等资源，不用担心路径问题，M$已经帮我们解决了，当然，CSS使用起来得小心了，因为它可以影响到全局。
最后，如果要在整个站点使用同一个主题的话，那么在Web.Config中指定吧。在System.Web下增加这样的东东<pages theme="ExampleTheme"/>，也可以在代码中指定主题，但是，是在Page_PreInit中也不是Page_Load中。
可怜的我正在公司长达两天的培训中与无情的睡魔做斗争，还能抽空出来写写学习笔记，已经很不容易了，请各位大虾手下留情，thanks！
首先，因为这篇内容很少，所以废话居多。顺便提一下，有空在这儿看我这种闲人的笔记并发表详论，甚至有空看电脑报的大叔，您不如多发点时间去做点大叔应该做的事吧。本人不仅虚伪，而且不喜欢任何有意义或无意义的批评。Just For Fun！ No Class！
CSDN不知道是为了强烈证明微软的SQL SERVER的强健性，每日每夜总要无数次地为我们展现连接池满的异常提示。为了删除发表上一篇文章时按了N次F5的后遗症，我再一次NF5，总算把多余的文章给删除了。
上次提到的是主题和样式，而这回要提到的是Master Page（有称呼为母页面或者主页面的，总觉得不是很清楚，因此使用英文原词）也是ASP.NET 2.0针对WEB特性的改进之一吧。感觉2.0把普通的WEB特性都引入到服务器了。Master Page从设计上来看有点像是服务器端的框架。
不管是ASP开始的include还是ASP.NET的用户控件，都是页面公共部分的一个解决方案。而2.0引入的Master Page则给了一个更好的选择。
Master Page实际上更像Dreamweaver的模板，只不是，它是实际存在的，而不像Dreamweaver只是存在于设计时。Master Page定义了一个共同风格站点的框架，在它的内部使用占位符来表示实际可以修改的部分。具体语法如下。
在页面的声明中取代Page指令的是Master指令，如<%@ Master Language="C#" %>。Master Page中的语法和普通的页面并没有多少差别，不过有一个占位符控件。如<asp:contentplaceholder id="FlowerText" runat="server"/>。在占位符中的内容则是它的默认内容，如果在使用这个Master Page的ASPX页面中没有为这个占位符提供新的定义，那么它将显示它的默认内容。为了和普通页面区分开来，Master Page以后缀名.master结束。
在页面中使用Master Page的方法是在Page的声明中的MasterPageFile属性指定Master Page的路径。在页面中可以通过定义占位符的内容来显示不同的效果。语法如下（例子Copy自QuickStart）：
<asp:content id="Content1" contentplaceholderid="FlowerText" runat="server">
With sunshine, water, and careful tending, roses will bloom several times in a season.
</asp:content>
实际上，页面中如果引用了Master Page，就只能定义占位符对应的内容了。那么不同文件的标题呢？在Page指令中。一个Title属性指定了每页的标题。
Master Page并没有解决链接的相对路径问题，非常遗憾，我们还是得使用绝对路径或者应用程序相关路径（ASP.NET特定的~）来为不同路径下的引用解决路径问题。
为了在代码中调用并修改Master Page的内容，在页面中加入如下指令<%@ MasterType VirtualPath="Site.master" %>。在代码中使用Master. 就可以调用Master中的内容了，这里的调用有两种方法，提供强类型方式的属性或者直接操作Master Page中的控件。
Master Page是可以嵌套的，可以轻松为一个站点制定一个总的框架，再为每个部分制定一个更详细的框架。
在一个Master Page中引用另一个Master Page的语法和Page是一样的，因此，它也只能包含asp:content这样的东东了。
最近的学习都缺少实践，但是对于（形容词略去大约500个字）的我来说，it's nothing。如果在实践后有什么新的看法，再写新的笔记吧。