WSS V3 和MOSS的SDK的正式版终于发布了，下载地址我不重新贴了，这里有：
WSS 3.0 SDK 与 MOSS 2007 SDK 正式版终于发布出来了 （Kaneboy's Blog）
抢先看一下正式版的SDK都包含了哪些新的内容：
总体来说SDK的内容完全充实了，之前很多页面都只有标题。
1）WSS V3 SDK
让我感到很激动的是，用VS开发自定义工作流的Sample，利用ASPX页面作为工作流交互的页面的例子ASPXCollectFeedback。这正是长久以来，我们希望看到的例子！
还包括工作流开发的VS模板以及一个文档WorkflowVSProjectTemplatesReadme.doc。
2）MOSS SDK
里面包括了WSS V3 SDk，OSSSDK2007和示例代码，Form Services SDK和ECM Starter Kit（企业内容管理）。
MOSS SDK包含的示例代码：
1、SSO示例
2、BusinessDataCatalogMetadataSamples：BDC示例
3、WebPartFiltersAndConsumers：过滤器WebPark示例
ECM Starter Kit中包含的是企业内容管理相关的白皮书和示例工程：
白皮书包括了：
1、如何使用和配置IRM功能
2、WorkflowSecurityTopics
3、如何在SharePointDesigner中导入Custom Actions
4、Office文档数字签名和RMS加密
示例工程：
主要包括了工作流方面，文档转换（Document Convertor），记录管理（Record Management）三个方面的内容
总体来说，很多的解答了我们最近关注的问题，比如SSO，工作流，CustomActions，IRM，记录管理，BDC等。
这个SDK的新信息很多，赶紧下载......
MOSS的列表相比之前的版本有了很多增强，内容类型，列表文件夹，版本控制，列表索引等特性的增强。因此，利用列表作为内容存储和维护的介质变得很方便。但是大家在做应用的时候一个重要的考虑就是，列表的性能问题。少量数据列表的应用列表的性能没有问题，但是当列表的数据达到了万数以上的时候，MOSS的列表的性能表现如何呢。为此，做了个测试，希望结果能给大家一个参考。
1）测试环境
操作系统：（VPC 2007 RC1中的虚拟机系统）Windows Server 2003
系统分配内存：1G
CPU：Intel PM 1.7G
MOSS版本：Microsoft Office SharePoint Server 2007 RTM
2）测试列表
测试用的列表是一个网站集顶级网站下自定义列表，自定义字段如下。
列表用文件夹来分类内容，测试用的内容存储在“新闻快报”文件夹中。
3）测试内容
1、测试列表默认显示页面的显示速度（AllItem.aspx）
主要测试为“标题”字段建立索引前后的速度变化
注：MOSS中可以为列表的某些字段建立索引（列表设置->栏设置），增强列表的访问速度
2、代码访问的性能
本测试是创建一个Layouts下的自定义web应用程序，取出List里面“新闻快报”文件夹下的内容填充页面上的GridView（每页显示20条记录）。
整个过程分3个步骤：
Step1：查询得到“新闻快报”文件夹下的ListItemCollection
利用，SPList.GetItems(SPQuery query)
利用tempquery.ViewFields="<FieldRef Name='Author' /><FieldRef Name='Title'/>";可以设置查询时候返回哪些字段；
测试中分了两种情况来查询：
情况1）：查询所有字段
情况2）：只查询特定字段
Step2：根据ListItemCollection生成DataTable作为GridView的数据源
利用两种方法：
方法1）遍历ListItem，根据每个ListItem创建一个DataRow，创建DataTable；
方法2）利用SPListItemCollection.GetDataTable()，遍历取到的DataTable，创建符合条件的DataTable;
Step3：GridView的数据绑定
给每个标题加链接，绑定数据
4）测试结果和讨论
1、默认显示页面打开速度
该测试中，整个列表中含有8000条数据，“新闻快报”文件夹有2000条数据，每页显示100条
未建立索引：7秒
建立索引后：2秒左右
结论：给列表字段启用索引可以提升访问速度
2、代码访问性能
该测试均基于对列表标题做了索引的基础上。
测试了“新闻快报”中含有2000条数据（列表总共8000条数据）和15000条数据（列表共21000条数据）两种数据量下的性能。
单位：毫秒
结论：
a、利用两种方法生成数据源的速度差不多
b、利用ViewFields来设置查询字段可以显著提高访问速度
c、在数据量很大的时候访问速度不是很理想（这个还有调优的余地，见后文）
5）性能调优建议
0、SPListItemCollection的GetDataTable方法取不到隐藏字段，如果要取到隐藏字段请使用遍历列表的方法
除此之外，两种方法没有什么性能的区别
1、对列表字段启用字段索引，在大数据量的情况下很有必要
2、妥善利用SPQuery的查询限制
比如ViewFields，限定查询返回的字段，默认的隐藏字段默认都会被返回。
利用RowLimit，来限制返回的结果的数量，结合SPQuery的Query对Orderby的支持可以满足很多情况的应用；比如最新发布的10条新闻，就可Orderby创建时间，RowLimit=10这样来查询
Query Caml中在MOSS中支持Contain这样的模糊查询，可以用来过滤数据
3、对大数据量的查询中，只取你需要的数据
比如，用GridView的时候不要把所有的数据取出来交给GridView，让GridView来做分页。
而是，自己做分页，每次只取每页显示数量那么多（PageSize）的数据。即只取当前页要显示的数据。
如果当前页时第5页，每页显示20个数据，我只取第81-100条数据（这个需要和SPQuery的Orderby一起使用，这样你取出来的数据才是有序的）
在上面的测试中，我利用此方法，在大数据量的时候能再节约800毫秒左右的时间。
4、对大数据量的列表应用中，对数据进行归档
归档的数据存储在另外的地方，这样可以保证列表的活跃数据的访问速度
5、能少用对象模型的地方尽量少用
6、利用对象模型取数据的时间有一个极限，这是对象模型的限制
在测试的三个步骤中，最耗时间的是在第二个步骤，确切地说是第一次访问SPListItemCollection的属性或者方法的时候。
SPListItemCollection的内部机制是在SPListItemCollection myitems = SPList.GetItems(SPQuery query)这个方法执行后，myitems里面并不含有数据，只是记录query的查询条件
只有当你第一次访问SPListItemCollection的属性或者方法的时候，myitems内部会有一个EnsureListItemsData的私有方法来初始化数据，
这个方法运行的时间就是利用对象模型取数据的极限时间。
