使用Excel Servcie连接数据库等数据源，并发布Excel文件后，可以在浏览器中打开Excel文件，并可以看到外部数据，但是点击“Refresh All Connections”（刷新所有连接）的时候，会遇到以下问题：
Data Refresh Failed
Unable to retrieve external data for the following connections:
Connection_Name
The data sources may be unreachable, may not be responding, or may have denied you access.
Verify that data refresh is enabled for the trusted file location and that the workbook data authentication is correctly set.
遇到这个问题的时候，你可以尝试在服务器上依次运行下面三个命令：
1. stsadm -o set-ecssecurity -accessmodel delegation -ssp sspname
不出意外的话，应该刷新就没有问题了。
QuickPart QuickPart 大家都知道是我们大名鼎鼎的Kaneboy 同学的大作，是用户控件包装器的杰出代表，是进行可视化Web部件开发的重要工具。
使用QuickPart的一般过程是：
1）先创建一个Web工程，新建用户控件，然后编译发布网站，得到我们需要的ASCX和dll文件；
2）部署QuickPart，并在网站上激活QuickPart Feature；
3）把Web应用程序的Trust Level该成可以使用Web部件；
4）把ASCX拷贝到Web应用程序的wpresources文件夹下，把dll拷贝到相应的bin目录下；
5）在网站上添加QuickPart，编辑属性，选择相应的ASCX文件；
6）现在，你可以使用包装好的用户控件了。
我想QuickPart再方便点 如果，我们想自动把开发的用户控件和dll部署好，然后能直接在网站上拖入一个包装了用户空控件的QuickPart就能使用了，添加Web部件的时候，丝毫感觉不出来是使用了QuickPart，那我们该怎么办呢？
我们首先需要了解一下Web Part的dll和.webpart文件的关系：
同样的一个QuickPart.dll，使用不同的.webpart描述文件可以把其描述成不同的Web Part。在.webpart文件里面指定WrappedUserControlPath就可以设置默认加载的用户控件了，再在.webpart文件里设置一个有意义的Title，这样同样一个QuickPart.dll在你的Web Part选择页面中就会对应出现多个更有意义的可用Web Part了。
利用.webpart文件我们解决了在网站上添加QuickPart，再选择加载哪个User Control的麻烦。
我们还没有解决怎样自动把ASCX文件和dll拷贝到相应目录下的问题。
Solution里面的Assembly Element有一个子Element叫做ClassResources，用来部署程序集的资源，所以我们可以把ASCX文件作为dll的资源，使得WSP可以帮我们完成这个部署，比如我们要部署IparkDebugPartUC.dll这个用户控件的程序集，它对应的资源会在bin\wpresources\IparkDebugPartUC \路径下（注意路径最后的文件夹就是程序集的名称），所以，我们在WSPBuilder下创建如下的文件夹结构：
把dll拷贝到80\bin目录下，ascx文件拷贝到80\bin\wpresources\IparkDebugPartUC \路径下
利用Solution的Assembly以及ClassResource我们解决了自动拷贝部署ASCX和dll的问题。
WSPBuilder生成WSP文件的时候manifest文件里面会自动为程序集添加CodeAccess相关的设置，所以修改Web应用程序的TrustLevel也就不需要了。
---------------------------------解决方案开始了------------------------------
所以我们的解决方案就是：
1）首先根据“[Best Practice]如何在SharePoint团队开发中利用WSPBuilder”中介绍的，创建好一个WSPBuilder项目来做Web Part的打包部署调试；创建好需要的文件夹结构，添加一个WSPBuilder Blank Feature，形成如下类似的样子：
注意，wpresources下面的文件夹必须和你要生成的用户控件所在的dll的名称一致。
2）创建一个Web Application项目，在项目里面创建一个.webpart文件，注意type这个metadata用来表示对应的dll是哪个，这里当然就是我们的QuickPart里面的包装器类型了。
<?xml version="1.0" encoding="utf-8"?> http://schemas.microsoft.com/WebPart/v3" > Microsoft.PRC.SharePoint.ConsumerQuickPart, QuickPart, Version=1.0.0.0, Culture=neutral, PublicKeyToken=2d0bb71b2dd16f9e " /> <property name="WrappedUserControlPath" type="string">~\wpresources\IparkDebugPartUC\IparkDebugPartUC.ascx</property>
这样，这个Web Application项目就形如：
把IparkDebugPartUC.ascx和IparkDebugPart.webpart文件设置为Copy Always：
在项目属性的Build Events中添加Post-build命令：
copy "$(TargetDir)IparkDebugPartUC.dll" "$(SolutionDir)IparkSolution\80\bin\";
3）修改WSPBuilder项目中IparkDebugPartFeature的elements.xml，在Elements节中添加
<Module Name="WebParts" List="113" Url="_catalogs/wp">
4）好了，你的解决方案样子就变成了：
首先build一下IparkDebugPartUC项目，然后在“IparkSolution”上右键菜单中，点击“Build WSP”，生成WSP文件，然后在右键菜单中可以看到Deploy和Upgrade都变成可用了，然后你就可以deploy这个解决方案了。转到你的网站集，激活IparkDebugPartFeature，你就可以在网站的Web Part列表中找到这个Web部件了：
你可以在你的Web Application项目上右键菜单的WSPBuilder菜单中点击“Attach to IIS Worker Processes”，开始调试你的用户控件了。
当你刷新用户控件所在页面，你的Visual Studio就会开始Debug了：
---------------------------------解决方案结束了------------------------------
补充
本文关注SharePoint开发的Assembly Development（何为Assembly Development，请参见 http://msdn.microsoft.com/en-us/library/bb428899.aspx ）
WSPBuilder 到目前为止，我觉得WSPBuilder 是SharePoint社区中最好的辅助开发工具之一（VSeWSS 1.3 CTP版本有一些功能就是“模仿”了WSPBuilder，呵呵）。
WSPBuilder的特点是根据文件夹结构来生成WSP文件，这是我个人觉得WSPBuilder最好的特性，也是最有用的功能 。现在，CodePlex上WSPBuilder提供了Visual Studio Addin的安装项目，该Extensions也可以在Visual Studio 2008上使用，该Extensions使得WSPBuilder更好的融合到Visual Studio的开发操作中，安装完“WSPBuilder Extensions 1.03 - Visual Studio Addin (0.9.8.0830) ”后，你打开Visual Studio可以有如下WSPBuilder项目：
在创建好的WSPBuilder项目后，右键点击项目可以看到以下WSPBuilder菜单：
以上菜单中，值得注意的是以下两个：
> Build WSP: 创建WSP文件，仅仅是创建而已，不会帮你部署！有很多时候我们其实只需要WSP文件（使用VSeWSS的人应该很希望VSeWSS也能这样）
> Attach to IIS Worker Processes: 不用在点好几步，然后查找w3wp.exe进程，然后附加了，只要点一下即可开始调试！
SharePoint的团队开发 在SharePoint团队开发，我感觉比较焦点的话题有几点：
0）团队开发怎么个模式比较好；
这个请先看看http://msdn.microsoft.com/en-us/library/bb428899.aspx ；
然后，我补充一点我个人的看法：
> 你会需要一个集中代码管理服务器，SharePoint开发集成环境，SharePoint测试服务环境，然后你会想要自动编译部署（WSPBuilder为你的这个愿望提供了很好的基础）
> 我偏向于程序员每个人都有自己的SharePoint开发环境（与生产环境相同的版本），环境中的Visual Studio有Web Application开发模板，安装WSPBuilder 的Visual Studio Extensions。
> 如果有条件开发人员的SharePoint环境使用虚拟机为好（如果SharePoint环境坏了，恢复快，好处肯定不止这个）。
> 另外，开发人员应该有一个非Windows Server的环境（用来自己做测试用，模拟一个真正的开发机和客户机环境，所有的开发测试都在SharePoint环境里面做是不明智的，很多时候你会发现当用客户机访问的时候，问题才能暴露）。也就是说，或者开发人员本机是非Windows Server环境，虚机是SharePoint开发环境；或者是本机是SharePoint环境，有一个非Windows Server的虚机环境。
1）开发的各种SharePoint部件（事件处理、Web Part、模板等）怎么方便的组合起来集成部署（知道用WSP，但是总是没有找到比较好的实施的方法）；
做Solution Package的最主要的问题在于
a、如何正确的使用Solution Schema里的Element来部署不同的开发产出；
b、编写正确的manifest.xml文件，打包成WSP文件
WSPBuilder的好处就在于，你需要做的就是把开发出来的东西放对文件夹！其他一切交给WSPBuilder
使用WSPBuilder自己的模板创建出来的项目，WSPBuilder会自动生成正相应的文件夹结构
所以，我的做法是使用WSPBuilder项目加上Visual Studio的Post-Event来满足要求：
1、专门创建一个WSPBuilder Project，作为维护创建WSP文件的文件夹结构的项目（也就是说专门用来生成WSP文件的项目）；
2、为不同的功能模块（某个Web Part、事件处理程序等）创建不同的项目，这样方便进行代码管理，工作分配，多人协作，创建的项目加入到第一步创建的解决方案中；
3、然后接着就是在WSPBuilder Project项目中，创建文件夹，直到每个功能模块对应的项目都能在该项目中找到相应的文件夹；对于每个功能模块对应的项目则在Post-Built中加入命令行脚本，使在编译通过以后，把编译的结果拷贝到第一步创建的项目的文件夹目录下。
---------------------------------例子开始了----------------------------
举个例子，你创建一个WSPBuilder的项目作为维护生成WSP文件的项目：
创建一个Web Part项目（用的是VSeWSS的Web Part模板），加入到解决方案中
在WSPBuilder项目中，添加一个叫DemoWebPartFeature的Blank Feature：
解决方案变成：
我会把自动生成的elements.xml文件删除，然后修改feature.xml文件：
把ElementManifests节改成以下样子：
<ElementManifests>
然后在WSPBuilder项目中创建出80\bin目录，这时候解决方案样子如下：
然后，对DemoWebPart项目做一些设置，首先把WebPart1.webpart和WebPart1.xml文件的属性改成“Copy Always”，这样在该项目的Debug目录中会出现这两个文件:
接下来，就是在Post-built中添加Copy命令行，把生成的文件拷贝到WSPBuilder项目对应的文件夹下：
copy "$(TargetDir)DemoWebPart.dll" "$(SolutionDir)WSPBuilder\80\bin\";
这样，整个项目的初始创建和设置就完成了，把项目迁入到代码管理服务器中，以后就不需要再改动这些设置了。
当你编译DemoWebPart项目的时候，WSPBuilder项目的文件夹下就会是如下样子：
在WSPBuilder项目的文件夹里面就已经有了所有DemoWebPart相关的文件了，然后我们可以在WSPBuilder项目中创建WSP文件（Deploy和Upgrade菜单在第一次点击Build WSP后才会变成可用）
所有在WSPBuilder解决方案中的项目右键点击都会出现以上菜单，可以方便的点击“Attach to IIS Worker Processes”来调试。
---------------------------------例子结束了----------------------------
这样的话
> 开发人员的工作过程就是 ：从代码管理服务器上获取解决方案的最新版本，然后迁出自己开发的项目，直接选择Deploy Solution，WSP会生成并自动部署到他的环境中，然后在代码中设置断点，点击“Attach to IIS Worker Processes”即可进行调试。
> 集成人员的工作过程 ：从代码管理服务器上获取最新的项目版本，然后Build WSP，把WSP部署到开发集成服务器上。这个过程，大家可以想象，使用自动build部署的方案完全是可以完成的。
2）可视化Web Part开发的最佳实践；（下一篇文章，我会介绍一个WSPBuilder和QuickPart合作进行Web Part开发的好方法）
在现在的SharePoint中默认我们新建Web应用程序的时候，SharePoint会帮我们新建一个对应的应用程序池。
当我们为某个Web应用程序扩展新的应用程序的时候，SharePoint会让扩展出来的和被扩展的Web应用程序使用同一个Application Pool。在这里，推荐你为扩展出来的Web应用程序也创建一个新的Application Pool，可以使用和父级的Web应用程序的Application Pool一样的配置 。这样做的目的只有一个，优化性能。
关于Application ：
每个Application Pool会对应一个w3wp.exe进程，w3wp.exe这个进程将在你访问www应用程序的时候启动。 这个服务器端的进程不会在你关闭了客户端浏览器以后,就马上关闭的.那是因为Http是无连接的访问,当你关闭了web网页,不会返回相应的关闭信息,所以W3WP.EXE这个进程不会因为你关闭了web应用程序而关闭. IIS会负责处理w3wp.exe进程。 在应用程序池的配置中,"空闲超时"中设定合适的时间,系统默认的是20分钟.设定好指定的时间,那么在这个时间范围内没有在访问应用程序,那么系统会自动的关闭W3WP.EXE这个进程的。
SharePoint默认的出错界面，对于最终用户来说有时候真是不友好：
怎么自定制的处理错误呢？
一般的ASP.Net的项目我们可以在global.asax文件中添加Application_Error方法来在全局范围内处理错误。
但是在SharePoint中我们没有办法这么做，所以我们只能通过写自定义的HttpModule来实现自定制的出错处理了。
具体的可以参考这篇Blog：
Catching unhandled exceptions in SharePoint
http://blogs.msdn.com/jannemattila/archive/2008/02/04/catching-unhandled-exceptions-in-sharepoint.aspx
我们知道SharePoint 的Solution Schema里面有很多Element都是涉及到部署某个文件的，比如：
FeatureManifest
TemplateFile
ApplicationResourceFile
Resource
ClassResource
DwpFile
RootFile
Site definitions
但是这些文件到底会被部署到服务器的什么位置呢，在SDK中没有详细的说明，查了一下，具体应该是：
Features <FeatureManifest>:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\
Template Files <TemplateFile>:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\
Application Resources <ApplicationResourceFile>:
C:\Inetpub\wwwroot\wss\VirtualDirectories\{virtual app port}\resources
Global Resources <Resource>:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\
Assemble ClassResource<ClassResource>:
C:\Inetpub\wwwroot\wss\VirtualDirectories\{virtual app port}\wpresources\程序集名称\
Web Parts <DwpFile>:
C:\Inetpub\wwwroot\wss\VirtualDirectories\80\wpcatalog
Root Files <RootFile>:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12
Site definitions:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\SiteTemplates
参考自以下文章：
SharePoint Solution Manifests
Creating Advanced Solutions for SharePoint 2007
就我的认识，SharePoint Designer的无代码工作流设计器在SharePoint中有两个作用，一个是设计列表的工作流，另一个是给DataForm Web part提供Custom Action（自定义列表操作）的支持（在上一篇文章中我叙述过相关的内容[SharePoint Designer -3]DataForm Web Part中的数据操作 ）。
不管是哪种使用方法，使用无代码工作流设计器的最终的结果都是：SharePoint会在网站的Workflows文件夹下面创建相应的文件（有XOML文件，工作流配置的XML文件，规则的rules文件，以及很多的asp页面，xoml和xml文件是一定存在的），然后给列表添加一个工作流关联（association）。其中很重要的一个文件是*.wfconfig.xml文件，其形式大致如下：
< WorkflowConfig >
< Template
BaseID ="{963BA7F4-2105-4793-85BB-C1D90367D961}"
DocLibID ="{8a493f4e-22e4-4f34-aefd-55325667ef0f}"
XomlHref ="Workflows/工作流 1 /工作流 1.xoml"
XomlVersion ="V4.0" >
</ Template >
< Association
ListID ="{32a8da29-ac60-4e06-86b8-70d4780e563a}"
TaskListID ="{6822A246-52D5-4BA8-BCBE-826D17620BE7}"
StartOnChange ="true" >
</ Association >
< ContentTypes >
</ ContentTypes >
< Initiation URL ="Workflows/工作流 1/工作流 1.aspx" >
< Fields />
< Parameters > </ Parameters >
</ Initiation >
</ WorkflowConfig > 其中DocLibID是Workflows文档库的GUID，ListID是这个工作流绑定到的列表的GUID。
我们可以通过备份还原网站来迁移部署SharePoint Designer设计的工作流。
但是，当我们备份还原网站后，SharePoint Designer设计的工作流在新的网站中不能工作！
问题出在两个地方：
1）新的网站中工作流对应的*.wfconfig.xml中的DocLibID和ListID不能更新到新网站的对应列表的GUID；
2）列表与相应工作流的关联（Association）丢失了。
根据对问题的分析，我们可以找到方法来重建并绑定工作流。
1）首先更新*.wfconfig.xml文件的DocLibID和ListID
2）重新绑定工作流
SharePoint Designer设计的工作流绑定需要利用WebPartPagesWebService的ValidateWorkflowMarkupAndCreateSupportObjects 和AssociateWorkflowMarkup 方法。
基于以上的分析，我的解决方案是：
1）在Workflows的文件夹下面维护一个Lists.xml文件，形式如下：
<? xml version="1.0" encoding="utf-8" ?>
< Lists >
< List Name ="test" ID ="{23d0e43d-b6bf-4670-b69f-871a63f77941}" > </ List >
< List Name ="custom workflow process" ID ="{76ed547a-aa40-4aab-86e2-5e525ea49e1d}" > </ List >
</ Lists > 为什么维护这样一个列表呢？因为网站备份在还原后，列表的名字不会变，但是GUID会变！所以，维护一个存储所有绑定了SharePoint Designer无代码工作流的列表的ID和Name对应关系的XML文件，方便之后更新*.wfconfig.xml文件用。
2）在网站还原以后，通过一下的ReAttachWorkflows方法来更新*.wfconfig.xml文件，并绑定工作流到相应的列表，代码如下：
public static void ReAttachWorkflows(SPWeb objWeb)
{
string strXOML = string .Empty;
string strConfig = string .Empty;
string strRules = string .Empty;
string strConfigPath = string .Empty;
string strVersion = string .Empty;
string strLists = string .Empty;
SPList objWorkflowList = null ;
try
{objWorkflowList = objWeb.Lists["Workflows "];}
catch
{objWorkflowList = objWeb.Lists["工作流 "];}
System.IO.StreamReader objReader;
SPFile Filelists = objWorkflowList.RootFolder.Files["Lists.xml "];
objReader = new System.IO.StreamReader(Filelists.OpenBinaryStream());
strLists = objReader.ReadToEnd();
objReader.Dispose();
System.Xml.XmlDocument xmlLists = new System.Xml.XmlDocument();
xmlLists.LoadXml(strLists);
foreach (SPListItem objItem in objWorkflowList.Folders)
{
SPFolder objFolder = objItem.Folder;
foreach (SPFile objFile in objFolder.Files)
{
objFile.CheckOut(false , string .Empty);
objReader = new System.IO.StreamReader(objFile.OpenBinaryStream());
if (objFile.Name.EndsWith("xoml "))
{
strXOML = objReader.ReadToEnd();
objReader.Dispose();
}
if (objFile.Name.EndsWith("rules "))
{
strRules = objReader.ReadToEnd();
objReader.Dispose();
}
if (objFile.Name.EndsWith("xml "))
{
strConfig = objReader.ReadToEnd();
objReader.Dispose();
strConfigPath = objFile.ServerRelativeUrl.Substring(objFile.ServerRelativeUrl.IndexOf(objWeb.Name) + objWeb.Name.Length + 1);
System.Xml.XmlDocument xmlConfig = new System.Xml.XmlDocument();
xmlConfig.LoadXml(strConfig);
//update GUID of the 'Workflows' document library
xmlConfig.SelectSingleNode("/WorkflowConfig/Template/@DocLibID ").Value = "{ " + objWorkflowList.ID.ToString() + "} ";
System.Xml.XmlNode xmlNodeList = xmlConfig.SelectSingleNode("/WorkflowConfig/Association/@ListID ");
System.Xml.XmlNode xmlNodeListOrigin = xmlLists.SelectSingleNode("/Lists/List[@ID=' "+xmlNodeList.Value.ToLower()+"'] ");
//update GUID of the list to be associated
xmlNodeList.Value = "{ " + objWeb.Lists[xmlNodeListOrigin.Attributes["Name "].Value].ID.ToString() + "} ";
strConfig = xmlConfig.OuterXml;
objFile.SaveBinary(System.Text.Encoding.UTF8.GetBytes(strConfig));
}
objFile.Update();
objFile.CheckIn(string .Empty);
}
Microsoft.SharePoint.SoapServer.WebPartPagesWebService objWebPartPages = new Microsoft.SharePoint.SoapServer.WebPartPagesWebService(objWeb);
string strResult;
strResult = objWebPartPages.ValidateWorkflowMarkupAndCreateSupportObjects(strXOML, strRules, strConfig, "2 ");
//associate with list
string param1 = strConfigPath;
string param2 = strVersion;
strResult = objWebPartPages.AssociateWorkflowMarkup(param1, param2);
}
xmlLists = null ;
}
一些想法 ：
1）了解了SharePoint Designer工作流的工作原理了，我们似乎是可以在一定程度上重用一下用SPD设计出来的工作流呢？
思路可以是这样：两个列表必须具有相同的字段（至少是与工作流相关的字段要一样，然后把Workflows文件夹下面的对应的工作流的文件夹复制一个，修改*.wfconfig.xml文件（更新路径，把绑定的列表的GUID更新，然后用ReAttachWorkflows把工作流绑定好。
从原理上来说这样做是行得通的，当然我并没有试过：）
WSS V3 和MOSS的SDK的正式版终于发布了，下载地址我不重新贴了，这里有：
WSS 3.0 SDK 与 MOSS 2007 SDK 正式版终于发布出来了 （Kaneboy's Blog）
抢先看一下正式版的SDK都包含了哪些新的内容：
总体来说SDK的内容完全充实了，之前很多页面都只有标题。
1）WSS V3 SDK
让我感到很激动的是，用VS开发自定义工作流的Sample，利用ASPX页面作为工作流交互的页面
还包括工作流开发的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 的私有方法来初始化数据，
这个方法运行的时间就是利用对象模型取数据的极限时间。
