Kaneboy's SharePoint Blog

经常有人问我这个问题，SharePoint服务器将连接配置数据库的连接字符串保存在什么地方？虽然其他SharePoint服务器场设置都是保存到了配置数据库里面，但连接配置数据库本身的连接字符串，肯定是只能存放在SharePoint服务器上的。

简单来说，SharePoint服务器将这个连接字符串信息保存在注册表中，具体位置是在"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Secure\ConfigDB"节点的"dsn"键值中。

 

提示：在注册表里面进行更改，是不被微软正式Support的，所以不要尝试做这样的操作！

如果不了解什么是Application Page，可以参考我以前写过的这篇文章。SharePoint 2010的页面模型没有太多的变化，基本和2007保持一致。对于开发人员而言，为SharePoint 2010创建一个Application Page，相比2007倒是方便了很多，因为Visual Studio 2010提供了很好的工具支持。

如下图所示，开发人员可以直接在一个SharePoint项目中添加一个Application Page：


在SharePoint 2010中，自定义Application Page默认仍然是从Microsoft.SharePoint.WebControls.LayoutsPageBase类继承而来：
 

除了在工具上的支持之外，SharePoint 2010的Application Page也已经可以使用网站公用的Master Page了，这意味着在设计师为网站设计了一个自定义的Master Page之后，Application Page也能呈现出与网站内容页面一致的效果了。

如下图所示，通过指定Application Page页面的<@ Page>标签中的"DynamicMasterPageFile"属性（注意不是"MasterPageFile"）的值，就能让Application Page直接使用用户当前所浏览网站的Master Page。
 

"DynamicMasterPageFile"属性的值可以是：
■ "~masterurl/default.master"：表示将使用SPWeb.MasterUrl属性所标识的Master Page，默认是网站母板页样式库中的"v4.master"文件。
■ "~masterurl/custom.master"：表示将使用SPWeb.CustomMasterUrl属性所标识的Master Page，默认它和SPWeb.MasterUrl的值保持一致，都是引用的"v4.master"。

如果你仍然希望让Application Page使用"14\templates\_layouts"目录下的"application.master"或"applicationv4.master"，那么不要使用"DynamicMasterPageFile"属性，而仍然应该使用"MasterPageFile"属性。

虽然通过Application Page的"DynamicMasterPageFile"属性能让Application Page使用网站的Master Page，但系统管理员也可以取消这项设定。在SharePoint 2010管理中心的Web应用程序管理中，通过将下图所示的选项设置为“否”，就能让Application Page不能引用网站的Master Page：


当然也可以通过Object Model来完成同样的操作：
 

如果通过上面的这两个方法，不允许Application Page使用网站的Master Page，同时又在"<@ Page>"中指定了"DynamicMasterPageFile"属性，那么Application Page会在"14\templates\layouts"目录中寻找"v4.master"。

最后，下面这几个特殊的Application Page，由于它们可能需要在任何场合（比如在用户没有通过认证的情况下）下被显示，所以它们都会使用"simple.master"这个最简Master Page：
■ Login.aspx
■ SignOut.aspx
■ Error.aspx
■ ReqAcc.aspx
■ Confirmation.aspx
■ WebDeleted.aspx
■ AccessDenied.aspx

Q：我在安装新版本的QuickPart，替换已有的旧版本时，总有问题，应该怎么办？
A：请到QuickPart项目网站，下载“How to Uninstall QuickPart”文档，然后按照文档中的说明，先从服务器上彻底删除旧版本QuickPart，然后再重新安装新版本QuickPart。

Q：我能修改QuickPart的源代码，添加自己想要的新功能吗？
A：请到QuickPart项目网站，下载“Source Code”包，然后修改源码自己编译即可。

Q：我下载了QuickPart源码项目，用Visual Studio打开后，会提示错误？
A：QuickPart 1.03版本的源码项目使用了Visual Studio 2008 + VSeWSS 1.3，请确认你使用了正确的Visual Studio版本，并安装了VSeWSS 1.3扩展包。

QuickPart 1.03下载页面

上周末，在SharePoint 2010 Day技术活动上，我做了一个纯演示的课程，演示了Visual Studio 2010中所包含的SharePoint 2010开发功能。



下载更高清晰度的WMV文件。

WPManager（Web部件管理器）
用于在SharePoint2007上部署、卸载Web部件，无需编写dwp/webpart描述文件，无需编写manifest，无需手动修改web.config，只需要打开生成的dll文件，选择部署位置，点击“部署”就可以一切搞定。支持dll、cab和wsp三种部署方式。同时支持部分Web部件的卸载功能，同时还有个彩蛋。
地址：http://wpmanager.codeplex.com

OSSEventManager（事件处理程序管理器）
可以方便的在一个列表上部署、挂载、卸载SharePoint 2007的列表条目事件处理程序。
地址：http://osseventmanager.codeplex.com

Friendly Query
使用类似T-SQL语句的形式进行SharePoint列表查询，无需任何CAML。之前写过一篇blog：点击这里
地址：http://fquery.codeplex.com/

清除已删除用户
如果使用自定义Membership Provider来实现SharePoint网站用户认证，从自定义用户数据源中删除了用户之后，还需要手工从SharePoint网站中删除对应的SharePoint用户。这个工具可以帮助管理员自动清除那些已从数据源中删除的用户。
地址：http://sptoolscn.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=38497

在自己的blog上发布计划的好处之一，就是可以督促自己。如果当2010年年底的时候，这些计划没完成，就请大家尽情的BS我吧。

1、搞清楚SharePoint 2010。这包括Silverlight、WCF、PowerShell、jQuery等等所有将用到的东西。
2、写完这本书。
3、学会Python，至少能在GAE上写一个应用。
4、把往年的欠账还了。欠账包括：看完《C++ Primer 3rd》（我是在2002年买进这本书的）、《WF高级程序设计》（Chai同学好心送了我一本，可我一直扔在书柜里面）、《敏捷软件开发》（我承认，这本书也在我手里好几年了）、《代码大全 2rd》（以前只看完了一半）。
5、至少听50个ESL Podcast。

如果我们使用一个SharePoint网站来存储部门/团队的文档，通常会按照我们想要的结构，预先在网站中建立好相应的文档库和文件夹。比如，我们会创建一个“技术文档库”，来存放技术类别的文档，同时创建一个“业务文档库”存放业务类别的文档，在“技术文档库”中，还可能按照编程语言的种类，建立诸如“CSharp”、“C++”、“Java”之类的文件夹，将技术文档按照它们所属的类别，再放置到相应的文件夹中。

但是，无论管理员将结构建立得多么好、多么完整，用户很可能并不会按照文档实际的类别，将文档上载到正确的文档库和文件夹中。SharePoint 2010的内容管理器，能帮助网站管理员实现自动化的文档路由和存储。在用户将文档上载到网站之后，网站的内容管理器会按照事先设置的规则，自动将文档移动到正确的地方。

内容管理器的规则，基本上基于两种判断条件：
1、文档的内容类型。例如，属于“技术文档”内容类型的文件，移动到哪里哪里，而属于“业务文档”内容类型的文件，又是移动到哪里哪里。内容管理器规则只能处理继承自“文档”内容类型的内容类型，这意味着内容管理器只能管理文件类型的内容，而不能处理其他列表项内容类型。
2、属性的值。基于第1种判断条件，管理员还可以再基于文档的属性，设置判断条件。比如，“技术类别”属性的值等于“Web程序”的文档，移动到哪里哪里。第2种判断条件不能独立于第1种存在。

内容管理器是一项网站级别的功能，而并非网站集级别。所以，首先需要在网站功能管理中，启用“内容管理器”功能：
 

在网站中启用了内容管理器功能之后，网站中会多出来一个“放置库”文档库。这个“放置库”是内容管理器的核心之一，实际上，所有内容管理器规则都是应用到“放置库”。

然后在网站管理页面中，会多出来“内容管理器设置”和“内容管理器规则”链接：
 

内容管理器设置界面中，是对整个网站的内容管理器功能，进行全局的设置。

如果选择了“将新内容提交到库”选项，那么无论用户是将文档上载到网站的什么地方，这个文档都会被自动移动到“放置库”中，以对其应用规则。但是我发现Beta2中似乎有Bug，即使管理员选中了这个选项，用户上传到其他地方的文档也不会自动移动到“放置库”，这样只有上载到“放置库”中的文档，才会被应用规则。


如果选中了“允许规则将其他网站指定为目标位置”选项，那么在规则中，就能将上载的文档移动到其他网站。但是其他网站的目标位置，必须事先由管理员在“管理中心 - 一般应用程序设置 - 配置发送到连接”设置之后，才能使用。
 

自动创建子文件夹的选项非常有用，这样可以避免在一个文件夹中，存放太多的内容。不建议在一个文件夹中，存放超过5000个文件。


如果目标位置已经存在同名文件，那么下面的选项将决定内容管理器如何处理这种情况。但是如果管理员选择了使用版本控制，但目标文档库又并未启用版本控制功能，那么内容管理器仍然是使用自动在文件名后面添加唯一字符的方式，来进行处理。


保留文档的审核日志和属性，有助于在记录管理中对文档进行持续管理。


“规则管理员”可以让管理员指定哪些人可以设置内容管理器规则。如果一个用户是网站管理员，但是并非规则管理员，他也不能管理内容管理器规则。如果一个用户是规则管理员，但并非网站管理员，他仍然不能管理内容管理器规则。


接下来，就是为内容管理器创建规则。每个规则都有优先级，优先级高的规则会先被执行，这样如果一个文档符合多个规则的条件，那么只有优先级最高的规则会被应用到文档。


下面的截图就是按照提交的文档的内容类型，进行条件筛选。“替换名称”可以用于同时处理多个相关的内容类型（比如有父子继承关系的内容类型）的情况。
 

“基于属性的条件”可以让管理员再基于选中的内容类型的必填属性，来设置过滤条件。


下面是在添加了2条规则之后的情景，两条规则实际上都是针对一种“技术文档”内容类型，但是第1条规则还加上了额外的属性条件过滤，来将“技术文档”中设置的是C#与Web类别的技术文档，单独存放到一个专门的地方。由于第1条规则所匹配的文档实际上是第2条规则所匹配的子集，也就是说，第2条规则覆盖了第1条规则，所以为了避免文档被应用第2条规则，管理员需要将第1条规则的优先级设置得比第2条规则高：
 

配置好了内容管理器之后，当用户在网站中上载了文档之后，系统会自动提示它，内容管理器已经将文档自动转移到了新的地方，并且会显示出文档所在位置的URL路径：
 

有了内容管理器，用户在上载文档时，就不再需要考虑到底将文档上载到哪个地方才合适。文档所在位置的选择，被交给了内容管理器，按照管理员所设置的规则，对文档进行自动的路由和分类。

在SharePoint 2007中，我们可以在网站集中定义或定制内容类型，然后在网站集里面的所有网站中使用这些内容类型，内容类型提供了一种集中管理数据与信息类型的方式，使得信息的结构定义，与信息的实际存储能够分开。但是在2007版本中，内容类型并不能被跨网站集使用。如果我们希望所有网站集都能使用同一个定义的内容类型，就必须将其封装为Solution Package，部署到各个Web应用程序当中。

SharePoint 2010为了让管理员可以方便的在整个服务器场范围中共享同一组内容类型，新增了内容类型集线器的功能。你可以指定一个网站集为“集线器中心”，将它的内容类型发布出来，凡是“订阅”了内容类型发布的其他网站集，就能自动将发布出来的内容类型同步到自己的内容类型库当中。

内容类型集线器是通过Managed Metadata Service这个服务应用程序来运作，所以，需要发布和订阅内容类型的网站集，必须与同一个Managed Metadata Service服务应用程序关联起来。每一个Managed Metadata Service服务应用程序实例，都只能指定一个网站集，作为内容类型集线器“中心”，由它来发布内容类型，而其他网站集只能作为“订阅者”，“订阅”被发布的内容类型。下图是一张内容类型发布和订阅示意图（来自www.chakkaradeep.com）。


在SharePoint 2010管理中心的服务应用程序管理中，选中Managed Metadata Service，然后点击Ribbon中的“属性”按钮：


在属性对话框的最下方，填入需要作为内容类型集线器“中心”的网站集路径，这个网站集里面定义的内容类型，将可以发布出来：


然后再次选择Managed Metadata Service服务应用程序代理，点击Ribbon中的“属性”按钮：


选中与内容类型集线器相关选项前面的复选框：


然后，在指定作为内容类型集线器“中心”的网站集里面，你可以从网站内容类型库中选择一个内容类型，然后通过点击“管理此内容类型的发布”链接，来发布这个内容类型：


SharePoint 2010服务器上定义了2个内容类型集线器相关的定时器作业，来自动进行内容类型的发布和订阅同步。它们在后台以指定的周期，自动运行以完成发布和同步操作。我们可以在管理中心网站的“监控 - 计时器作业状态”中，找到这两个定时器作业，然后手工强制立即执行（能手工立即启动一个计时器作业，也是SharePoint 2010的一个新功能）。

首先，找到“内容类型集线器”计时器作业，然后点击“立即运行”按钮：


然后，在定时器状态页面中，切换视图到内容类型“订阅者”网站集所在的Web应用程序，找到“内容类型订户”定时器作业，并手工立即启动它的运行：


然后在内容类型“订阅者”网站集的网站内容类型库当中，您应当就会看到被同步过来的内容类型了。在“订阅者”网站集管理页面中，有一个“内容类型发布”链接，点击后能看到所有被同步过来的内容类型：


注意，被同步到“订阅者”网站集中的内容类型，是不能被修改的。如果你希望在“订阅者”网站集中，对从集线器“中心”同步过来的内容类型再进行适当的修改，例如增加一个字段，那么可以再创建一个新的内容类型，并继承自那个同步而来的内容类型，然后按照要求修改新内容类型即可。

在一个企业中，有时候需要一个专门的Metadata库，用来保存各种预定义的Metadata。有了Metadata库，就能方便的为企业中的各种数字内容、数字资产应用上各种定义好的Metadata，或是用Tag的方式，为各种内容打上Tag。当为各种内容指定了Metadata或Tag之后，无论是搜索，还是浏览，都能利用这些Metadata和Tag，对搜索结果或内容视图进行分类和过滤。

在SharePoint 2010中，提供了Managed Metadata Service，它是一项服务应用程序，能为整个服务器场，甚至整个企业（通过将一个服务器场的Managed Metadata Service发布出去），提供一个集中的Metadata存储和管理中心。

打开管理中心的服务应用程序管理，就能看到Managed Metadata Service。选中它后，点击上方Ribbon中的“管理”按钮，就能打开术语库管理工具。

提示：如果是第一次打开术语库管理工具，可能会发现你没有权限对术语库进行更改。你需要将你自己添加到术语库管理员中：


术语库管理工具是专门用来管理Managed Metadata Service所存储的所有术语（Term）的工具。管理员可以使用它，预先定义好企业中所需要的各种术语。在术语库管理工具中，可以通过组（Group）、术语集（Term Set）来为术语进行分类。基于组，可以进行权限的定义（哪些人是术语组的管理员，哪些人是术语组的参与者）。术语可以有一个或多个子术语，一个术语也可以同时位于多个术语集中。


在默认的设置中，所有新建的术语集和术语都可以被用于Tag的作用，管理员可以手动启用或关闭这个功能：


如果管理员希望SharePoint网站的普通用户，也可以手动向术语库中添加新的术语条目，那么需要将术语集的提交政策改为“打开式”（默认是出于关闭状态，也就是只有管理员才能通过术语管理工具添加术语）：


对于每个术语，管理员都可以对它进行各种操作，其中“重复使用术语”是指将此术语复用在另一个术语集中，但又并非复制一个术语，而是将一个术语“映射”到多个不同的地方：
 

有些术语可能有同义词，比如“IE”与“Internet Explorer”，管理员可以为一个术语指定一个或多个同义词：


除了位于管理中心的这个全局术语库管理工具之外，网站集也有一个网站集级别的术语库管理工具，通过它，网站集管理员可以管理一个网站集所有的术语：


要在SharePoint网站中使用这些术语，只需要为列表、内容类型添加类型为“托管元数据”的栏即可。比如，在为企业所有的员工建立了术语之后，就可以为“公司项目”内容类型添加一个名为“项目负责人”的栏（注：这是一个例子，并不表示鼓励使用术语库来维护企业员工信息，用户配置文件通常是维护企业员工信息的更好工具。）：


然后为这个元数据栏指定所绑定的术语节点，只有选定的术语节点中的术语，才能被填入到栏中：


然后，在为列表添加这种内容类型的列表项时，就能看到我们添加的元数据栏：


用户填写元数据栏的值的时候，随着用户输入文本，这个文本框会自动从术语库中检索匹配的术语，并显示出符合的候选术语：


或者，也可以直接浏览所有可用的术语并选择：
 

在为列表项指定了元数据之后，用户甚至可以不再基于传统的列表视图方式浏览列表项，而是使用基于元数据过滤，来查看列表项。比如，用户可以基于“项目负责人”这个元数据的值，来对所有项目列表项，进行浏览。从列表设置中打开“元数据导航设置”：
 

配置好了元数据导航之后，在列表视图的左下角，就能看到所列出的元数据术语，点击每个术语，就能看到与这个术语相关的列表项：


或是使用这个术语筛选器（截图上的“密钥”字样是中文版本词语翻译错误），直接筛选显示列表中的列表项数据：
 

除了对列表项和文档之外，我们还能将术语用做标签。在SharePoint 2010网站中，右上角会有一个“Tags & Notes”按钮，如果你希望给当前浏览的页面做一个标签，直接点击这个按钮即可：


然后在弹出的对话框中，就能填入定义好的术语了：
 

Managed Matadata使企业可以集中管理元数据，并通过它构建企业的分类体系（Taxonomy）。Managed Matadata作为一个服务应用程序，可以发布给整个服务器场、其他SharePoint服务器场，甚至企业内部的各种其他应用系统。

（因为是按照自己的思绪写的，所以写得比较乱，有些部分不一定准确，后续会有更新…）

Create Custom Service Class

Service类用来定义这个自定义“Service”，也是各种功能的入口点。它继承SPIisWebService，并实现IServiceAdministration（以接入到管理系统中）。

[Guid("E828358E-E24C-4D78-BE87-C69D458766F4")]

public class KaneboyService : SPIisWebService, IServiceAdministration

Service类通常实现二个构造函数：

·        默认构造函数

·        一个参数为SPFarm对象的构造函数

public KaneboyService() { }

public KaneboyService(SPFarm farm) : base(farm) { }

IServiceAdministration的方法：

·        CreateApplication()：创建一个SPServiceApplication对象。只有在通过运行psconfig.exe或farm configuration wizard创建Service Application时才会调用它（所以对于自定义SPService，它通常不会有机会被调用）。

·        CreateProxy()：创建一个SPServiceApplicationProxy对象。与CreateApplication()类似。

·        GetApplicationTypeDescription()：返回对此Service的描述信息。

·        GetApplicationTypes()：返回Service Application的类型。

·        GetCreateApplicationLink()：如果希望可以在管理中心的“管理服务应用程序”中新建此Service Application实例，那么需要实现此方法并返回新建Service Application页面的URL。

Create Custom Service Instance Class

Service Instance用来描述运行在每个SPServer上的Service实例。它继承SPIisWebServiceInstance。

public class KaneboyServiceInstance : SPIisWebServiceInstance

Service Instance类的构造函数：

·        默认构造函数

·        参数如下的构造函数：

o   一个SPServer对象，表示运行此Service实例的Server

o   所对应的SPIisWebService对象

public KaneboyServiceInstance() : base() { }

public KaneboyServiceInstance(SPServer server, SPIisWebService service) : base(server, service) { }

Service Instance类需要实现的方法：

·        TypeName属性：描述此Service Instance的名称，显示在管理UI。

Create Custom Service Application Class

Service Application类是对Service Application的实现。它继承SPIisWebServiceApplication，并通常实现Service Contract接口。

[IisWebServiceApplicationBackupBehavior]

[ServiceBehavior(

        InstanceContextMode = InstanceContextMode.PerSession,

        ConcurrencyMode = ConcurrencyMode.Multiple,

        IncludeExceptionDetailInFaults = true)]

[Guid("933A11F0-7265-4694-97C0-FE04BFB370A5")]

public class KaneboyServiceApplication : SPIisWebServiceApplication, IKaneboyServiceContract

Service Application类的构造函数：

·        默认构造函数

·        带下列参数的构造函数：

o   Service Application名称

o   所对应的SPIisWebService对象

o   所使用的SPIisWebServiceApplicationPool对象

public KaneboyServiceApplication() : base() { }

private KaneboyServiceApplication(String name, KaneboyService service, SPIisWebServiceApplicationPool appPool) : base(name, service, appPool) { }

Service Application需要告诉系统，如何连接到WCF Service，所以它需要实现：

·        InstallPath属性：返回.svc所在的目录。

·        VirtualPath属性：返回.svc文件的名称。

如果在Provision这个Service Application的时候，还需要Provision数据库或其他资源，可以重载Provision()和Unprovision()方法。

创建（并Provision）一个Service Application不能直接使用它的构造函数，而是需要使用如下步骤：

·        创建Service Application至少需要用到如下信息：

o   Service Application名称

o   它所对应的SPService对象

o   它所使用的SPIisWebServiceApplicationPool对象

·        通过SPService.Applications.GetValue()，确定这个Service Application是否有其他实例存在。

·        使用它的构造函数，新建一个实例对象。

·        调用SPServiceApplication.Update()保存新建的实例。

·        调用SPServiceApplication.AddServiceEndpoint()为Service Application新建WCF Endpoint。

serviceApp.AddServiceEndpoint("http", SPIisWebServiceBindingType.Http);

serviceApp.AddServiceEndpoint("https", SPIisWebServiceBindingType.Https, "secure");

·        调用SPServiceApplication.Provision()以Provision它。

创建并Provision 自定义Service Application的方法，可以放到Service Application类中，以static method提供。管理员可以使用管理中心UI（位于”ADMIN”中的自定义.aspx，路径由IServiceAdministration.GetCreateApplicationLink()指定）或自定义powershell cmdlets来完成这个操作，所以在管理中心UI或自定义cmdlets中，需要调用这个static method。

WCF Artifacts

首先，需要一个自定义Host Factory类，继承自ServiceHostFactory。

public class KaneboyServiceHostFactory : ServiceHostFactory

它重载CreateServiceHost()方法，创建并返回一个ServiceHost对象。

public override ServiceHostBase CreateServiceHost(string constructorString, Uri[] baseAddresses)

{

ServiceHost serviceHost = new ServiceHost(typeof(KaneboyServiceApplication), baseAddresses);

serviceHost.Configure(SPServiceAuthenticationMode.Claims);

return serviceHost;

}

在”WebServices”这个mapped folder下面，需要放置自定义Service Application的.svc文件和定义WCF channel的web.config。.svc只需要通过标签告知Service和Factory类即可。

<%@ServiceHost Language="C#" Debug="true"

               Service="KaneboyServiceApp1.KaneboyServiceApplication, $SharePoint.Project.AssemblyFullName$"

               Factory="KaneboyServiceApp1.KaneboyServiceHostFactory, $SharePoint.Project.AssemblyFullName$" %>

web.config里面需要定义Service Application将使用的channel。

<configuration>

  <system.serviceModel>

    <services>

      <service name="KaneboyServiceApp1.KaneboyServiceApplication">

        <endpoint

          address=""

          contract="KaneboyServiceApp1.IKaneboyServiceContract"

          binding="customBinding"

          bindingConfiguration="CustomServiceHttpBinding" />

        <endpoint

          address="secure"

          contract="KaneboyServiceApp1.IKaneboyServiceContract"

          binding="customBinding"

          bindingConfiguration="CustomServiceHttpsBinding" />

       </service>

    </services>

    <bindings>

      <customBinding>

        …

      </customBinding>

    </bindings>

  </system.serviceModel>

  <system.webServer>

    <security>

      …

    </security>

  </system.webServer>

</configuration>

Register Service on Farm

将Service注册到Farm里面，需要创建Service和Service Instance对象，并将它们Persist到Config DB中（通过调用Update()）。注册可以通过一个Farm Feature的activate事件来实现。在新建Service和Service Instance对象之前，可以通过调用SPFarm.Services.GetValue()来确认是否Farm中已经注册了此服务。在Farm Feature的deactivate事件中，可以将相关的Service和Service Instance删除。

Create and Provision Service Application

新建Service Application的实例，可以使用管理中心UI（“管理服务应用程序”）或自定义powershell cmdlets来实现。如果是通过管理中心UI，可以在“ADMIN”中新建一个.aspx，并将其路径在Service类中通过IServiceAdministration.GetCreateApplicationLink()告知系统。

无论哪种方法，最关键的是，如何将Service Application所使用的SPIisWebServiceApplicationPool对象传递给新建Service Application的代码。如果是使用.aspx，可以使用” ~/_admin/IisWebServiceApplicationPoolSection.ascx”控件，然后通过IisWebServiceApplicationPoolSection.GetOrCreateApplicationPool()得到用户选择的App Pool。如果是使用cmdlets，那么就通过SPIisWebServiceApplicationPoolPipeBind类来得到App Pool信息。(Check MSDN to get detail information.)

------------------ “Server”(App Server)与”Client”(WFE)的分割线 ----------------------

WCF Artifacts

在”WebClients”这个mapped folder下面，将一个”client.config”文件放置到一个自定义目录中，此文件中包含了告知Service Application Proxy通过哪个channel连接到Service Application的配置信息。

<configuration>

  <system.serviceModel>

    <client>

      <endpoint

        name="http"

        contract="KaneboyServiceApp1.IKaneboyServiceContract"

        binding="customBinding"

        bindingConfiguration="CustomServiceHttpBinding" />

      <endpoint

        name="https"

        contract="KaneboyServiceApp1.IKaneboyServiceContract"

        binding="customBinding"

        bindingConfiguration="CustomServiceHttpsBinding" />

    </client>

    <bindings>

      <customBinding>

            …

      </customBinding>

    </bindings>

  </system.serviceModel>

</configuration>

Create Custom Service Proxy Class

Service Proxy类用来描述service consumer。它继承SPIisWebServiceProxy，并实现IServiceProxyAdministration。

[SupportedServiceApplication("933A11F0-7265-4694-97C0-FE04BFB370A5", "1.0.0.0", typeof(KaneboyServiceApplicationProxy))]

[Guid("44203351-1E42-413E-BAAA-42A4A0788A8D")]

public class KaneboyServiceProxy : SPIisWebServiceProxy, IServiceProxyAdministration

Service Proxy类的构造函数：

·        默认构造函数

·        参数为SPFarm对象的构造函数

IServiceProxyAdministration的方法：

·        CreateProxy()：创建一个SPServiceApplicationProxy。

·        GetProxyTypeDescription()：返回对此Service Proxy的描述。

·        GetProxyTypes()：返回Service Application Proxy的类型。

Create Custom Service Application Proxy Class

Service Application Proxy类定义了连接到Service Application的接口，Service Consumer通过它实现对Service的调用。它继承SPIisWebServiceApplicationProxy类。

[IisWebServiceApplicationProxyBackupBehavior]

[System.Runtime.InteropServices.Guid("6339C282-E7D3-4B0D-94DF-2D09773FDF80")]

public class KaneboyServiceApplicationProxy : SPIisWebServiceApplicationProxy

Service Application Proxy类的构造函数：

·        默认构造函数

·        包含以下参数的构造函数：

o   Service Application Proxy的名称

o   所对应的Service Proxy对象

o   Service Application的Endpoint URL

public KaneboyServiceApplicationProxy() : base() {}

public KaneboyServiceApplicationProxy(String name, KaneboyServiceProxy serviceProxy, Uri serviceEndpointUri) : base(name, serviceProxy, serviceEndpointUri)

{

_loadBalancer = new SPRoundRobinServiceLoadBalancer(serviceEndpointUri);

}

由于Service Application通常需要Load Balance的能力，所以Service Application Proxy通常会包含一个SPServiceLoadBalancer类型field，它可以使用SharePoint内置提供的SPRoundRobinServiceLoadBalancer类来实例化。SPRoundRobinServiceLoadBalancer类需要给出Service Application的URL来进行构造。

Service Application Proxy要实现的方法：

·        一个根据Service Application的Url，获取Endpoint Configuration名称（对应到client.config中”<Endpoint>”节点的”name”属性）的方法（如“GetEndpointConfigurationName()”），Endpoint Configuration的名称通常是“http”和“https”。

·        一个创建并返回ChannelFactory<T>的方法（如“CreateChannelFactory()”），它需要读取client.config中的信息。

private ChannelFactory<T> CreateChannelFactory<T>(string endpointConfigName)

{

// open client.config

string clientConfigPath = SPUtility.GetGenericSetupPath(@"WebClients\KaneboyServiceApp1");

Configuration clientConfig = OpenClientConfiguration(clientConfigPath);

ConfigurationChannelFactory<T> factory = new ConfigurationChannelFactory<T>(endpointConfigName, clientConfig, null);

// configure the channel factory for IDFx claims auth

factory.ConfigureCredentials(SPServiceAuthenticationMode.Claims);

return factory;

}

·        一个获取Channel（Service Contract接口）的方法，通过调用ChannelFactory. CreateChannelActingAsLoggedOnUser<T>()，来获取Channel。

private IKaneboyServiceContract GetChannel(Uri address)

{

    // get the endpoint config name

    string endpointConfigName = GetEndpointConfigurationName(address);

    ChannelFactory<IKaneboyServiceContract> channelFactory = CreateChannelFactory<IKaneboyServiceContract>(endpointConfigName);

    IKaneboyServiceContract channel  = channelFactory.CreateChannelActingAsLoggedOnUser<IKaneboyServiceContract>(new EndpointAddress(address));

    return channel;

}

结合以上的Helper方法，就可以拿到可以透过WCF远程调用Service Application的Channel对象。

创建（并Provision）一个Service Application Proxy的步骤如下：

·        调用Service Application Proxy构造函数，新建实例。

·        调用SPServiceApplicationProxy.Update(true)将对象persist到ConfigDB中。

·        调用SPServiceApplicationProxy.Provision()。

类似Service Application，创建Service Application Proxy的方法可以放到此类中，以static method的方式提供。

Create and Provision Service Application Proxy

新建并Provision Service Application Proxy，类似Service Application，可以使用管理中心UI或自定义powershell cmelets实现。

如果是使用管理中心UI，可以在创建并Provision了Service Application之后，紧接着创建Service Application Proxy。如果是创建cmdlets，可以使用SPServiceApplicationPipeBind来得到其所对应的Service Application。

Invoke Service

通过Service Application Proxy调用Service Application所提供的功能，步骤如下：

·        获取SPServiceApplicationProxy对象，可以通过SPServiceContext.GetDefaultProxy()来获得。

·        调用SPServiceApplicationProxy对象所持有的SPServiceLoadBalancer对象的BeginOperation()获取一个SPServiceLoadBalancerContext对象，然后通过使用SPServiceLoadBalancerContext.EndpointAddress拿到这次请求需要调用的Endpoint Url。使用此Url，并通过调用Service Application Proxy中的Helper方法，拿到IChannel对象，也就是实现了Service Contract的对象。

·        调用IChannel上的方法

·        使用IChannel.Close()关闭连接。

·        调用SPServiceLoadBalancer.EndOperation()告知完成了Load Balance操作。

(这一辑是有关开发的内容)

在开发SharePoint 2007应用程序的时候，性能是我们很可能面临的一大挑战。我们最不希望看到的，就是用户刷新一个页面之后，需要等上好几秒钟（或更长时间），才能看到页面缓慢的打开。如果真的遇到性能上的问题，那么在进行性能优化之前，第一个需要了解的事情，就是“系统性能瓶颈在哪里？”也就是说，如果不能找到系统运行缓慢的原因，那么性能优化也就无从着手了。

找到系统瓶颈的工具有很多，从Windows Server内置的性能监控器，到SQL Profile、CLR Profile等等，都是非常有用的工具。而对于一个SharePoint页面，似乎则没有什么特别好用的恶工具，能够快捷明了的告诉开发人员，页面上的各个部件对于性能，都会造成什么样的印象，都各自占用了多长的运行周期。

开发人员面板（Developer Dashboard）是在SharePoint 2010中一个新增的功能。它是一个位于页面下面的信息面板，能直接显示出当前页面上的各个组件的运行时间、当前页面的运行会产生哪些数据库调用、每个数据库调用又会占用多少时间等等信息。如果发现某个页面运行缓慢，那么通过开发人员面板，开发人员就可以迅速找到导致页面慢如蜗牛的罪魁祸首了。

下面是SharePoint 2010工作组网站默认首页的开发人员面板：
 

其中包含了页面上各个控件的执行时间：
 

当前Web请求的一些有用信息：


当前页面所引发的所有数据库的调用，以及它们的执行时间：


点击每个数据库调用，还能看到这个数据库调用的详细信息，包括所执行的SQL语句全文、调用堆栈、IO Stats等信息：
 

开发人员面板是一个服务器场级别的设置，它可以在三个状态间进行切换：关闭（默认状态）、打开、按需打开。当它处于打开状态时，每个页面（包括网站页面和应用程序页面）的下方都会显示开发人员面板。当它处于按需打开状态时，每个页面的右上角会有一个管理员可见的小图标，管理员可以点击这个小图标切换显示或关闭开发人员面板。

更改服务器场开发人员面板设置的方法是使用stsadm.exe命令行指令：


上面的指令中，-pv参数的值可以是on、off、ondemand，分别表示打开、关闭、按需打开。

如果愿意，你还可以在代码中更改服务器场开发人员面板的设置：


不过要注意的是，由于SharePoint的安全限制，上面的代码只能运行在管理中心网站的页面上，或是独立的Windows应用程序（比如命令行程序）中。如果试图在普通网站的页面上运行这些代码（比如将代码放到一个Web Part中，然后将其部署到一个工作组网站页面上），将会抛出SecurityException。

Office Web Applications可以让用户在浏览器里面，直接查看和编辑Word、Excel、PowerPoint和OneNote文档，而无需在客户端安装相应的Office程序。

在网站集功能管理中，激活“Office Web Apps”，就能在当前网站集使用Office Web Apps功能了：


Office Web Apps的使用非常简单，直接使用文档的操作菜单中的“在浏览器中查看”和“在浏览器中编辑”菜单项就可以了：


当然，由于浏览器的能力限制，不可能做到像Office客户端程序那样丰富的编辑功能：
 

能“插入”的项目也比较少：


但有些功能还做得像模像样：


这是编辑PowerPoint幻灯片的样子：


利用Office Web Apps播放幻灯片的效果相当不错，包括幻灯片中的动画效果，都基本能够原样的表现出来。

Office Web Apps另外一个值得一提的特性，就是它能支持多人同时在浏览器里面对一个文档进行编辑（但Word和PowerPoint文档在Beta2中不支持多人同时编辑，不知道正式版的情况如何）。

比如，一开始只有一位同志在浏览器中编辑这个Excel工作表，在右下角能看到“1 person editing”的提示信息：

这时，另外一位同志在浏览器中也打开了同一份文档开始编辑：


这时页面右下角会立即出现提示信息，告诉用户，有另外一位同志，也开始编辑这个工作表了：


点击后能看到当前编辑者的名单： 


那么多人打开同一份文档编辑的时候，是如何反应别人的编辑情况呢？Office Web Apps会自动将每个人的修改信息，发送给其他编辑者，这样，在每个人的浏览器中，都能反应出所有编辑者的修改结果。

最后，Office Web Apps是否仅支持IE浏览器呢？答案当然是否定的。在上面的两人同时编辑文档的截图中，您应该能看出来，右边那位同志使用的，是FireFox浏览器。

更新（2009/12/08）：
1、对于多人同时编辑文档，支持情况如下：
Excel文档支持多人通过Office Web Apps同时编辑；
Word和PowerPoint文档支持多人通过Office客户端程序打开文档实现同时编辑；
OneNote文档支持多人通过Office Web Apps或通过Office客户端程序打开文档同时编辑。
2、Office Web Apps支持仅允许用户通过浏览器查看文档，而不允许用户下载文档。

在Office 2010客户端程序中，增加了SharePoint Workspace 2010。这是一个SharePoint 2010的“客户端”程序，可以用来离线同步SharePoint网站的文档和数据。

在SharePoint网站的“网站操作”菜单中，有一个“同步到SharePoint工作去”菜单项：

文档库的Ribbon菜单中也同样有这样一个菜单项：
 

点击这个“同步到SharePoint工作区”，就会自动启动客户端的SharePoint Workspace：
 

当然，我们可以仅仅将所需要的网站内容同步到本地：


配置完成了同步之后，在SharePoint Workspace中就能看到与SharePoint网站同名的工作区：
 

打开这个工作区，我们就可以看到同步到本地的所有SharePoint数据了：


可以看到，我们通过SharePoint Workspace，基本上可以完成绝大部分对SharePoint网站数据的操作。比如，对于文档库，我们同样可以在SharePoint Workspace中进行新建、上载、签入/签出、搜索等等操作。当然，对文档的查看和编辑更是没有问题。


操作列表中的列表项，也同样没有问题。比如，为“任务”列表新增一个列表项：


列表中定义的视图，同样也能在SharePoint Workspace中得到体现：


在SharePoint Workspace中对网站数据进行了修改之后，可以通过“同步”按钮将数据同步回SharePoint服务器。


有了SharePoint Workspace，用户能够更加方便的使用SharePoint。用户可以将SharePoint网站的数据同步到自己的笔记本电脑上，这样即使下班回家，也能通过SharePoint Workspace访问和编辑SharePoint网站上的数据，第二天回到办公室，连接上网络之后，再将更改同步回SharePoint服务器。

另外一个应用场景是可以更方便的发布信息。如果一个用户每天都需要向SharePoint网站的某个列表中发布数据，例如，向“通知”列表发布新的部门通知，有了SharePoint Workspace，用户不必在浏览器中打开SharePoint网站，而是可以直接在SharePoint Workspace中向“通知”列表中添加新的数据，然后再将这些数据同步到SharePoint网站。

有时候，我们会有一组关联度很高的文档，它们都是属于某个主题，或通常互相引用。比如，关于某个项目的一组Word文档，或是TechEd会议的所有SharePoint相关的幻灯片文档。对于这样一组关联度很高的文档，在SharePoint 2007中，我们要么将它们放在一个单独的文件夹中，要么单独创建一个文档库存放它们。SharePoint 2010增加了一个新特性：文档集，就是用来专门管理一组关联度很高的文档。

首先，在网站集的功能管理中，激活“文档集”功能：

然后，为希望使用文档集功能的文档库，添加上“文档集”内容类型：



然后在这个文档库的“新建文档”菜单中，就会增加“文档集”选项：


在新建文档集的窗口中，输入文档集的信息：
 

文档集被创建之后，会有一个专门的文档集页面，来让用户查看和管理这个文档集：
 

对一个文档集，我们可以对它进行相应的管理，包括为它设置单独的权限、为它附加工作流等等：


我们为文档集上载一组文档：


在文档库的视图中，一个文档集显示成一个项目（虽然它里面实际包含了多个子文档）：


当使用搜索功能的时候，文档集中的文档可以被直接搜索到，同时文档集本身也会被包含在搜索结果中：

在拿到SharePoint 2010 Beta2的安装文件之后，安装它整体而言并不太麻烦。博客园的wengnet写了两篇图文并茂的文章介绍SharePoint 2010的安装（这里和这里）。如果您在安装的时候遇到问题，下面是一些可能有帮助的信息：

1、安装序列号在这里。
2、动手安装之前最好仔细阅读这篇文章。里面包含了你需要下载的补丁、当与DC安装在一起时如何启用Office Web App等大量提示性信息。
3、这里有一篇非常完整的从头到尾安装SharePoint 2010的文章，全程有截图和说明。
4、如果在尝试安装一个虚拟机，可以参考这里，按照说明注册后下载一个指导的PDF文档。
5、这个版本毕竟还是测试版，不可能没有问题。如果遇到了安装和开发的问题，请参考这里。
6、如果在使用Forms Services时出现“StateServiceLocalizedException”异常，请参考这里。

花了一点时间，把微软发布的一份SharePoint 2010学习指南翻译成了中文。内容其实不是很多，就两页，主要是当前一些学习资料的链接。如果想开始学习SharePoint 2010，倒是一份不错的学习指引。



点击下载PDF文件

SharePoint Server 2010 Beta
Office Web Apps Beta
SharePoint Designer 2010 Beta (64-bit) (32-bit)
Visio 2010 Beta (64-bit) (32-bit)
Project Server 2010 Beta
Project Professional 2010 Beta (64-bit) (32-bit)
FAST Search Server for SharePoint 2010 Beta
Office Pro Plus 2010 Beta

所有的下载（除了FAST Search Server），都可以选择中文版。

使用过Office 2007的同学一定知道，Office 2007引入了一种全新的界面模式：Ribbon。在SharePoint 2010中，界面风格也将使用类似的Ribbon界面。Ribbon界面所显示的菜单和选项，将随着用户所在的页面以及用户当前可以进行的操作，而动态的进行调整。

下图是使用“Team Site”模板所创建出来的一个SharePoint 2010网站的首页：

在页面的上方区域，就能够看到相关的两个Ribbon面板：

其中“Browse”是标准的浏览模式，而“Page”，则表示了这个Ribbon面板中将放置与当前正在浏览的页面有关的页面操作。如果我们点击“Page”面板，就能够看到：

在“Page”这个面板中，包含了“Edit”（编辑当前页面）、“Check Out”（将当前页面签出）、“Edit Properties”（修改当前页面的属性）等按钮。有一些按钮本身是包含了子菜单的，比如“Edit”按钮：

如果我们点击“Edit”按钮，开始编辑当前页面，可以看到页面上方的Ribbon区域所显示的面板，也会自动调整为相应的编辑工具：

在页面编辑状态之下，我们可以使用Ribbon中的“Save”按钮，来保存我们所进行的更改：

现在让我们打开一个列表，可以看到，列表视图也发生了很大的变化。用户的所有操作，同样全部被放置到了上方的Ribbon区域：

对于列表而言，Ribbon区域中所显示的“List Tools”中的“Items”和“List”，分别表示了与列表项和列表相关的操作。比如，当我们点击“List”时，就能看到各种与当前列表相关的操作出现在了Ribbon区域：

现在让我们尝试添加一个新的列表项，这时可以看到另外一个界面上的重大变化，“对话框”的出现：

在2007版本中，几乎所有的界面都是通过单独的页面来实现，当用户需要添加或编辑列表项时，都是转到相应的页面，完成操作后再跳转回来。SharePoint 2010的“对话框”界面，使用户的操作更简洁，也减少了页面之间的跳转。

对于列表项的编辑，同样适用了“对话框”界面。除此之外，为了方便用户同时对多个列表项进行操作，列表视图中在每个列表项前面都添加了一个复选框，通过使用这个复选框，我们能一次对多个选中的列表项进行操作。比如，同时删除多个列表项：

或是在文档库中同时签出多个文档：

SharePoint 2010的列表还新增了一种编辑模式：Inline Editing。只要在列表视图中启用Inline Editing，用户就能够直接在列表视图中点击列表项左侧的编辑图标，编辑当前列表项，然后再通过点击左侧的保存图标，快速完成列表项的编辑：

这个系列的文章，是为了帮助大家更好的了解SharePoint 2010。拥有SharePoint 2007的经验能够帮助您更容易的理解本系列的文章，但我会尽量使没有SharePoint 2007经验的读者也能不困难的进行阅读。

下图是一张SharePoint 2010基本架构图，它简要的描述出了SharePoint 2010的基本结构。

当我们说“SharePoint 2010”时，实际上是包含了SharePoint Foundation 2010和SharePoint Server 2010这两个产品。SharePoint Foundation在之前的版本中，被称为Windows SharePoint Services（WSS）。SharePoint Foundation是SharePoint Server的基础构件，SharePoint Server依赖于SharePoint Foundation。我们可以在系统中仅安装SharePoint Foundation，而不安装SharePoint Server（比如，由于价格的原因），但是如果我们直接安装SharePoint Server，则会默认的安装上SharePoint Foundation。

如果本文中没有明确的指出，那么SharePoint 2010默认包含了SharePoint Foundation 2010和SharePoint Server 2010。

SharePoint 2010完全基于x64架构，且不再包含x86版本。这也就决定了SharePoint 2010所要求的硬件和软件环境：

1. 1. 服务器硬件必须支持x64；
2. 2. SharePoint 2010服务器的操作系统必须使用Windows Server 2008 x64或Windows Server 2008 R2 x64；
3. 3. SharePoint 2010服务器所使用的数据库必须是SQL Server 2005 SP2 x64或SQL Server 2008 x64。

如果您希望将现有的SharePoint 2007系统升级到SharePoint 2010，那么首先，必须将SharePoint 2007系统迁移至x64环境，包括硬件、操作系统和数据库，然后才能顺利的将SharePoint 2007升级到2010版本。

为了方便SharePoint开发人员，SharePoint 2010提供了一种方式，允许开发人员将其安装到64位的Windows Vista和Windows 7操作系统之中。这样，开发人员可以在自己安装了Windows Vista或Windows 7的开发环境中，使用Visual Studio 2010进行SharePoint应用程序开发。（后续文章将详细介绍如何在Windows Vista和Windows 7上安装SharePoint 2010。）

SharePoint是一个基于.NET/ASP.NET技术的Web应用平台。SharePoint 2010基于.NET Framework 3.5 SP1版本。没错，虽然SharePoint 2010的开发将主要使用Visual Studio 2010，但它使用并依赖于.NET 3.5 SP1，而并非.NET 4.0。

Office 2010（在本系列文章中，“Office 2010”指Office 2010系列的客户端软件，如Word、Excel、SharePoint Designer等）与SharePoint 2010有了更好的集成性。这体现在：

1. 1、 SharePoint Designer 2010功能更丰富，比如，它内置了更强大的工作流设计器，并且可以通过Business Connectivity Services直接连接到数据库；
2. 2、 在Visio 2010中，可以直接设计SharePoint 2010工作流，然后将设计好的流程导出至SharePoint Designer 2010的工作流设计器；
3. 3、 Groove 2007变成了SharePoint Workspace 2010，它现在可以将SharePoint网站中的文档库和列表数据，同步到客户端之中，以实现离线访问，同时允许用户在本地编辑文档库和列表数据，然后同步到SharePoint网站中。

为了迎接SharePoint 2010，决定订购一台新笔记本，用来进行SharePoint 2010开发、测试和演示。我对新装备的要求是：

1、轻便。由于我经常有机会进行演示和讲演（比如下个月即将开始的TechED China 2009），所以我希望这台新装备足够轻便，当我带着它外出时，不会让我感到太大的“压力”。
2、足够的性能。由于我的开发环境基本上都是建立在虚拟机里面，所以我希望它可以轻松的运行SharePoint 2010虚拟机。

最后我订购的是ThinkPad X200，它配置了酷睿2 P8600，6GB内存（单条4GB的笔记本内存太贵了，以后再升级到8GB吧），320G硬盘，而且，它还足够轻便。从昨天晚上拿到了它之后，就开始给它安装Windows Server 2008 R2，并使用它启动了一个SharePoint 2010的Hyper-V虚拟机。在为虚拟机分配了4.5GB内存之后，它运行得相当的流畅。:)

 

新装备到手之际，同时也听到了某些同志准备订购ThinkPad T400，8GB RAM，2GB Intel Turbo Memory的传闻...

从北京时间昨天晚上开始，随着SharePoint Conference 2009开幕，有关SharePoint 2010的NDA就结束了。这也就是说，无论是MVP，还是参加了SharePoint 2010 TAP的用户，都可以开始自由的在博客、论坛上撰写或讨论有关SharePoint 2010的内容。

在SharePoint Conference 2009的网站首页上，已经可以收看到会议第一天早上的Keynote视频。另外还有一些不错的视频也被放在了SharePoint Conference 2009会议网站上，比如SharePoint 2010 Customer Excitement。

刚刚上线的SharePoint 2010 Developer Center上面已经有了不少有价值的内容，比如2010 SDK。如果您是一名SharePoint Application Developer，那么SharePoint 2010 Developer's Evaluation Guide是一定要看的。如果你是一名SharePoint Administrator，那么也可以阅读SharePoint 2010 IT Pro's Evaluation Guide。

SharePoint 2010的公开测试版将在11月份发布。

一年一度的TechED将在今年11月5日-7日，在北京国家会议中心登场。今年的TechED取消了上海和广州站（金融危机的原因？），而只保留了北京站。对于不少华东华南的朋友来说，这真是一件纠结的事啊...在本次TechED China 2009中，当然少不了有关于SharePoint的课程，而其中大部分，都是有关于SharePoint 2010的。这应该也将是国内第一次SharePoint 2010技术课程的集体出场。

SharePoint 2010 新技术揭秘
SharePoint 2010 系统管理员秘籍
SharePoint 项目实施团队的成功之道
SharePoint内容管理及合规一致性
从隔靴搔痒到探囊取物 - SharePoint 2010数据访问新特性
用Visual Studio 2010构建SharePoint 2010应用实战体验
先睹为快 -- Office 2010全新生产力平台大揭秘
将分散的信息汇聚为知识和价值 - SharePoint 2010企业搜索
强强联手：Office 2010 与 SharePoint 2010协同办公
SharePoint 2010 Business Connectivity Services：外部业务数据整合利器
InfoPath 2010亮剑 -- 为SharePoint列表设计表单应用
SharePoint 2010 与 Access 2010 构建团队级数据应用

上面的课程中，粗体标注的是我主讲的课程。欢迎捧场！:)

更多有关TechED China 2009的信息，请参考TechED网站。完整课程表请点击这里。

大约一年前，我曾经在blog上写过一篇文章，讲述了我对于SharePoint解决方案开发模型的一些想法，其中包括了SharePoint解决方案开发的方方面面，从开发团队，到开发环境的建立、物理与逻辑架构的设计、开发流程、信息架构、测试等等等等。这些主题我相信对于SharePoint开发人员、架构师、项目经理而言，都是非常有价值的。

既然直到现在，国内仍然没有任何SharePoint开发书籍（当然也包括我的《SharePoint 2007 开发入门指南》）讲述上面这些主题，所以决定开始在自己的blog上面，陆续就每个主题，撰写一些文章。希望这些文章能帮助到SharePoint技术社区。

每每涉及到比“具体”技术细节更高一层的架构、流程、方法论的东西，通常都很容易引起争议。这是很正常的现象。这些主题和具体的诸如C#语法、怎么做一个Web Part等等都不相同，因为这些主题根本就不会有一个标准答案。每个人心中都对如何设计一个架构、如何实施某个流程都有自己的想法，而环境与条件的不一致，更是使得所谓的“最佳实践”在很多场景中都不适用。所以，如果你对我撰写的文章中的某些内容不认可，没有关系，这些文章中的内容本来就不是“金科玉律”，甚至在你所处的场景中根本就是错误的。这些文章只代表我个人的意见（但其中肯定有不少想法，来自MSDN以及其他人所撰写的博客和文档），同时我也希望它们能成为交流的一个平台。如果你对文章中的内容有意见和想法，欢迎留言。高质量、有价值的留言，通常都能让后来的阅读者受益良多。

任何软件项目的实施，都必须从实施团队开始。所以，首先要讲述的主题，是如何建立一个SharePoint实施团队。

从本质上来说，实施一个SharePoint项目，与其他类型的软件项目，诸如ASP.NET、PHP，都不会有根本的差别。所以一个SharePoint实施团队的组成，也基本上和一个标准的Web项目实施团队相同。在下面的角色描述中，我基本上只会描述和SharePoint相关的部分，而其他通用的内容则会尽量省略。

项目经理

项目经理是整个项目的管理者。他负责指派任务、记录和跟踪进度、向老板们汇报...总之，项目经理的工作就是要保证整个项目处于正常状态，并能顺利完成。在小型团队中，项目经理有可能同时兼任业务分析人员。

业务分析人员

业务分析人员应当与客户充分交流，弄清楚客户的业务需求、流程等等信息（越详细越好）。业务分析人员与架构师一起工作，撰写出应用系统的功能规格说明书（也可能叫其他名字），不管我们叫这份文档什么名字，它都应当至少包含有：
1、整个项目要解决的问题、目标
示例：“ABC公司是一家卖汽车的企业，它总共有300名销售人员，销售人员希望通过一个“客户管理系统”对他们各自的客户进行管理。在这个系统中，销售人员能够查看自己负责的客户、每个客户的详细信息、每个客户的订单历史记录等信息。同时，销售人员还需要通过这个“客户管理系统”提交季度销售预测报告...”
2、针对用户使用场景的User Cases
这里的User Cases信息，应当详尽的描述出用户使用系统的每个具体场景，它将作为整个团队的一个“基础文档”，架构师和开发人员根据这些信息，才能知道程序最终要实现的效果。每个User Case里面都要包含用户几乎每个操作的描述和说明，以及每个主要界面的图示（使用Visio或其他工具绘制），也就是说，它不能含糊，而应该清晰、明确、有针对性。
示例：“User Case 15 - 销售人员Dashboard”
“销售人员在“客户管理系统”主页上点击“Dashboard”按钮（参考User Case 5），就能够打开自己的Dashboard...Dashboard会自动校验当前浏览用户的身份和权限，如果的Dashboard以两栏的方式来展现信息（参考图15-3），其中左栏自上而下会包含5个链接，分别是...销售人员点击了左栏的“历史订单数据”链接之后，页面将转向到“历史订单数据”页面（参考User Case 26）...中间的向右箭头是一个可以允许销售人员将右栏折叠起来的图标，在点击它之后...销售人员可以点击右上角的“返回”图标，以返回到“客户管理系统”主页...”

功能规格说明书不涉及具体的技术细节，不包含如何实现每个场景的技术说明，不包含系统的设计内容。我们可以这样想象，假设团队中突然来了一个陌生人，他希望能了解这个团队到底在做一个什么项目，这个项目是干嘛的，实现了什么功能，我们可以将这份功能规格说明书给他，而他确实可以从这份文档中了解到他希望了解的这些信息。

这份文档不能由业务分析人员一个人独自写成，而一定要有技术人员（以架构师为主）的共同参与。一方面，架构师的参与可以保证规格说明书中的内容，在技术上是可行且合理的，另一方面，也有助于架构师从业务角度了解系统，明白客户的需求。

我个人对功能规格说明书的重要性非常推崇。在项目中，可能我们不会撰写详细的设计文档，可能我们不会撰写详细的部署文档，但一份详细的功能规格说明书确是不可缺少的。它的重要性体现在：
1、让团队中的所有人都明白我们要构建的是一个什么东西。如果没有这样的一份清晰的功能规格说明书，就不能保证团队的所有人都一致了解团队的目标。如果没有它，业务分析人员会根据客户的描述，在自己的大脑中想象出系统应该有的样子，然后口述给开发人员，并假设开发人员完全明白了自己大脑中的想法，而开发人员则会根据自己从业务分析人员那里听到的，在自己的大脑中又试图去想象系统做出来应该是什么样子的，并假设这就是业务分析人员想要的样子...总之，每个人都会根据自己的“想象”，去猜测别人的意图。而最后当开发人员把最好的东西给业务分析人员演示的时候，通常是业务分析人员大吃一惊：“我kao，怎么是这个样子？这根本和我告诉你的是完全不一样的东东...”而开发人员则会辩解：“胡说，这分明就是我根据你告诉我的要求做出来的...”
2、我们有了一个可以和客户讨论的东西。这份文档可以尽早的交给客户审阅，客户可以根据这份文档，了解到系统做出来会是什么样子，如果不满意，客户也可以及早的和开发团队进行沟通：“嗯，不对，在这个地方，其实我们更希望看到一个选择框，而不是用户自己填...”
3、它是业务分析人员与开发人员之间的一份“合同”。业务分析人员可以充分的假定，开发人员最后交付的，就是功能规格文档中所描述的样子，而开发人员也可以充分的假定，业务分析人员需要的，也是文档中所描述的样子。

值得一提的是，功能规格说明书并不会（也不应该）限制开发人员的“自由”。它仅仅包含对业务场景、系统功能的详细描述，但是不会写上应该如何实现。它肯定不会包含诸如“在这里，我们要创建XYZ类和ZYX类，前者用于从数据库中查询QWE表...”，也不会包含诸如“我们将使用3层结构，并由5个主要模块来构成整个系统框架...”之类的信息。如何设计、如何实现，应该由架构师和开发人员讨论并确定，而没有必要写到功能规格说明书里面。

架构师

架构师首先应当与业务分析人员一起撰写功能规格说明书，以保证其中所包含的内容在技术上的可行性，这同时也能保证架构师非常了解整个系统的业务需求。其次，架构师应该以功能规格说明书为基础，为整个系统设计物理架构和逻辑架构，将整个系统合理的拆分成各个更小的模块与组件，并将模块与组件的开发任务分配给开发人员。架构师还要与开发人员非常紧密的一起工作，与每位开发人员讨论并确定每个模块的实现方式。架构师应当是技术负责人，确保整个项目在技术上畅通无阻。

系统物理架构也就是整个系统在物理上、网络上的拓扑模型。整个系统需要多少台服务器？每个服务器是什么角色？网络设置应该是怎样的？是否需要DMZ区域中也要部署一台SharePoint服务器（如果用户需要从Internet访问的话）？或是使用DMZ中ISA Server来进行Internet发布？这些设计都是属于系统物理架构上的设计。

系统逻辑架构是从逻辑上描述整个系统的结构。整个系统有几个SharePoint服务器场？有几个SharePoint Web Application？几个Site Collection？每个Site Collection是做什么的？会包含哪些内容？为哪个群体的用户服务？各个不同区域的安全模型是怎样的？这些设计就属于系统逻辑架构设计。

子模块与组件的拆分也是架构师需要承担的工作。如何将整个系统拆分成更小的模块与组件？按何种方式与原则进行拆分？比如，是按照传统的N层架构来拆分（将“数据层”模块交给一个开发人员做，将“业务逻辑层”模块交给一个开发人员做，将“UI层”模块交给一个开发人员做...）？还是按照业务功能来拆分（将“客户数据维护”功能模块交给一个开发人员做，将“订单历史数据查询”功能模块交给一个开发人员做，而每个功能模块实际包含了实现那个功能所需的所有从数据到业务逻辑到Web Part展现相关的所有部分...）？不同的拆分方式，就决定了如何为开发人员分配工作，并会影响到后续一系列的诸如集成测试之类的环节。

开发人员

终于，开发人员登场了。开发人员的工作就是理解自己所负责的模块与组件相关的业务需求，仔细阅读（并可能参与编写）功能规格说明书，与架构师紧密合作，将功能实现出来。

作为一个SharePoint开发人员，是非常有挑战性的。需要学习和掌握的知识点非常的多，才可能从容不迫的将手头的开发任务完成。拥有强有力的SharePoint开发人员，是整个项目能否顺利完成的关键因素。

SharePoint开发人员需要掌握的知识包括：SharePoint、ASP.NET、XML、Windows Workflow Foundation、JavaScript、InfoPath，未来还可能需要加上Windows Communication Foundation、LINQ、Silverlight、PowerShell...

测试人员

当我说到“测试人员”时，实际上包含了两类人。一类是对开发人员写出的代码进行测试的人，这种人可能由开发人员（通过贯彻Unit Test流程）兼任，第二类则是在SharePoint解决方案开发过程中，进行集成测试和最终环境测试的人，这种人也可以由某位开发人员兼任。

集成测试是指，在一个独立的集成环境中（通常是一个“干净的”SharePoint服务器场），定期将所有开发人员交付的模块与组件部署进来，并对它们的功能以及它们相互之间的关联进行测试。一个集成测试环境对于SharePoint开发而言是必不可少的。

网络与系统管理员

网络与系统管理员是那些负责建立和管理开发团队所使用的各种环境的人。这些环境包括位于每个开发工作站上的开发环境，进行集成测试的集成服务器环境，进行部署前测试的最终测试环境，以及生产环境。网络和系统管理员负责将开发人员交付的模块与组件，部署到各个环境中（比如测试环境、生产环境）。将有了环境管理员，开发人员也可以快速的得到一个标准的SharePoint开发环境。网络与系统管理员可以由某位非常熟悉SharePoint管理的开发人员兼任。

当然，根据各个项目需求的不同，团队中还可能有其他的角色存在，比如美工、文档编撰人员等。这些我们就不再一一详述了。本系列的下一篇文章，将讲述SharePoint解决方案开发中所涉及到的各个环境。

这两天在忙着修饰自己部门的Team Site，老板提出了一个期望，想在Team Site首页上放一个Timeline，这样部门有什么新的事件、日程，都能在Timeline上展现出来。这件事本身并非特别麻烦，但是我们的Team Site是放在公司Hosting的SharePoint系统之中（公司提供SharePoint Hosting服务，每个人/部门可以根据自由要求，以自助的方式申请Site来使用），而公司Hosting的系统，是不允许各个网站的所有者使用任何Server Code（服务器端代码）的。从IT管理的角度来说，这也是非常合理的，但这的确大大限制了各个网站的使用者对各自的网站进行定制的能力。换句话说，我能使用的工具，只有SharePoint内置的各个Web Part，以及SharePoint Designer。（在SharePoint 2010中，提供了一个新的特性：Sandboxed Solution，来解决这个问题，各个网站集的管理员可以通过upload的方式，部署功能与权限受限的Solution Package到网站集之中，但又不会影响其他网站集和整个服务器场的安全与稳定。）

在经过一番考虑之后，我确认在不允许服务器端代码的前提下，是可以通过JavaScript和HTML的能力，实现一个Timeline的。下面这张图是最终实现后的效果：


这个Timeline分成了3栏，从上至下分别是日、周、月视图，用户可以使用鼠标对每个栏进行滑动操作，以查看之前和之后日期的各个事件。Timeline中的事件，来自于网站中一个日历类别列表中的数据，这样网站使用者只用在列表中添加新的事件，Timeline中就会自动显示出来：


实现的关键是两点：
1、使用JS从网站列表中，获取到所需的列表项数据；
2、使用JS和HTML，在SharePoint页面上渲染出Timeline。

首先，我在网站中使用“日历”列表模板，创建了一个新列表。由于在Timeline控件上，我只希望能够显示当天前后30天之内发生的事件，为了更容易的取到当天前后30天的事件列表项，我在列表中创建了一个新的视图，在这个视图中只显示事件开始时间是位于当天前后30天的事件。为什么创建这样的一个视图就能方便我们在页面上用JS获取想要的数据，看到后面大家就明白了。

为了让这个新视图能进行查询过滤，我为列表创建了两个新的计算类型字段，"30DaysBeforeStartTime"和"30DaysAfterStartTime"，下图显示了"30DaysBeforeStartTime"的定义方法：


"30DaysAfterStartTime"的定义方法也类似，只是公式变成了"=[Start Time]+30"。

很多人都不知道在计算字段中，应该如何使用公式。在这个页面上，有能够使用的所有公式和函数的说明，这里还有一些最常用的公式的示范。

有了这两个字段，我们就可以为新的视图来设置过滤条件了，通过下图中的条件，就能过滤出当天的前后30天之类的事件：


有了这个新的视图之后，我们就能保证，我们需要在Timeline中显示的数据，肯定都会被这个视图所包含。接下来我们进入到JS阶段...

如果要用JS获取SharePoint网站中的数据，比较靠谱的方法是用JS调用SharePoint的Web Services接口。SharePoint提供了不少Web Services接口，让我们可以在各种平台和语言中调用，其中就包括运行在页面上的JS。我们需要的是能够从列表中获取数据的Web Services接口，这个接口位于Lists Web Service里面，它提供了一个GetListItems()方法，让我们拿到列表项数据。其中，GetListItems()方法的第二个参数："viewName"，就可以让我们指定列表的一个视图，作为取数据的筛选条件。当然，我们也可以使用GetListItems()方法后面的参数来重新指定筛选条件，但是通过列表视图来制定筛选条件，要简单很多，而且修改起来也容易得多。

如何在JS中调用Web Services的方法在网络上能找到很多很多的文章，我就不再重复了。但我要推荐一个不错的JS库，使用这个JS库，可以免去手工构建SOAP包的麻烦，而且使用也相当的简捷。它包含许多的.js文件，将这些.js文件上载到网站的某个文档库中即可（实际上，并不一定需要复制所有的.js文件，比如，对于我的要求，我只用复制"SPAPI_Core.js"、"SPAPI_Types.js"和"SPAPI_Lists.js"即可）。我将所有这些乱七八糟的文件都放在一个名叫"SupportingFiles"的文档库中：


然后，用SharePoint Designer打开网站的母版页文件（默认是"default.master"），添加上对这几个.js文件的引用（图片上显示出还添加了对"http://simile.mit.edu/timeline/api/timeline-api.js"的引用，这个东东下面会讲到）：


使用上面所介绍的那个JS库，下面所示的代码就可以让我从一个列表中，将列表项取出来：

function getCalendarListItems()
{
    var lists = new SPAPI_Lists("网站URL");
    var items = lists.getListItems(
        "Timeline", // 要获取数据的列表的显示名称
        "{14CB7B04-46AA-421C-B6B2-C5FBEEBA9F5B}", // 视图的GUID，注意两边要加上大括号
        "", // 查询条件
        "", // 要返回的字段
        100, // 要返回的数据的最大行数
        "", // 查询选项
        null // 网站的GUID，null表示使用上面的SPAPI_Lists构造函数里面的网站URL所对应的网站
        );

    if (items.status == 200)
    {
        var rows = items.responseXML.getElementsByTagName("z:row");       
        return rows; // 如果获取数据成功，将所有数据放在一个数组中，然后返回
    }
    else
    {
        return null;
    }
}

通过JS拿到所需的日历事件数据之后，接下来，就是如何在页面上用HTML+JS渲染出一个Timeline。作为一个典型的ELC（Exist Library Caller），我首先想到的是到网上找找是否已经有人做过类似的东东，果然，在Google Code上就被我找到了一个，嘿嘿嘿...

在这个名为SIMILE Widgets的工具集中，包含了一个用JS实现的Timeline。经过在文档中一阵乱翻，下面的JS代码就能够帮我实现想要的效果（第一行不是JS代码，而是JS代码里面会使用的一个div元素，Timeline就是通过它显示出来）：

<div id="my-timeline" style="height: 120px; border: 1px solid #aaa; font-size: 9pt"></div>

var resizeTimerID = null;
function onResize() {
    if (resizeTimerID == null) {
        resizeTimerID = window.setTimeout(function() {
            resizeTimerID = null;
            tl.layout();
        }, 500);
    }
}
window.onresize = onResize;

function formatDateString(originDateStr)
{
    var yearStr = originDateStr.substr(0, 4);
    var monthStr = originDateStr.substr(5, 2);
    var dayStr = originDateStr.substr(8, 2);       
    return monthStr + "/" + dayStr + "/" + yearStr + " " + originDateStr.substr(11);
}

function createTimeLineAndEvents()
{
    var items = getCalendarListItems();
    if (items == null)
    {
        alert("cannot got items from list.");
        return;
    }
    var eventSource = new Timeline.DefaultEventSource();
    for (var i = 0; i < items.length; ++i)
    {
        var ows_EventDate = formatDateString(items[i].getAttribute("ows_EventDate"));
        var ows_EndDate = formatDateString(items[i].getAttribute("ows_EndDate"));
        var ows_Title = items[i].getAttribute("ows_Title");
        var ows_Location = items[i].getAttribute("ows_Location");       
        var eventDate = new Date(ows_EventDate);
        var endDate = new Date(ows_EndDate);
        var event = new Timeline.DefaultEventSource.Event(
            eventDate, //start
            endDate , //end
            eventDate, //latestStart
            endDate , //earliestEnd
            false, //instant
            ows_Title, //text
            ows_Location //description
        );
        eventSource.add(event);
    }

    var bandInfos = [
        Timeline.createBandInfo({
            trackGap:       0.2,
            width:          "60%",
            intervalUnit:   Timeline.DateTime.DAY,
            intervalPixels: 100,
            timeZone : 8,
            eventSource: eventSource
        }),
        Timeline.createBandInfo({
            showEventText:  false,
            trackHeight:    0.5,
               trackGap:       0.2,
            width:          "25%",
            intervalUnit:   Timeline.DateTime.WEEK,
            intervalPixels: 150,
            timeZone : 8,
            eventSource: eventSource
        }),
        Timeline.createBandInfo({
            showEventText:  false,
            trackHeight:    0.5,
               trackGap:       0.2,
            width:          "15%",
            intervalUnit:   Timeline.DateTime.MONTH,
            intervalPixels: 400,
            timeZone : 8,
            eventSource: eventSource
        })
      ];
      bandInfos[1].syncWith = 0;
    bandInfos[2].highlight = true;
    bandInfos[2].syncWith = 1;

    var timeLine = Timeline.create(document.getElementById("my-timeline"), bandInfos);
}

_spBodyOnLoadFunctionNames.push("createTimeLineAndEvents");

唉，实在是有点长，本来不想全部贴出来，可想到也许有人要用的话，所以就...另外，别忘了在母版页里面，添加对"http://simile.mit.edu/timeline/api/timeline-api.js"的引用（如上面的截图所示）。

把上面的这些JS代码（以及一个"div"标签）都放到一个单独的.htm文件中，然后在想要显示Timeline的页面上放一个内容编辑Web部件。通过设置内容编辑Web部件的属性，告诉Web部件从那个.htm文件中去拿要显示出来的HTML源码（这种方式能让我们直接使用SharePoint Designer编辑那个.htm文件中的HTML和JS源码，而不必使用内容编辑Web部件内置的那个笨拙编辑器）：
 

OK，完成。另外提一下，在SharePoint 2010中提供了专门的Client OM，它直接支持使用ECMAScript（标准名词解释：ECMAScript是一种由Ecma国际（前身为欧洲计算机制造商协会）通过ECMA-262标准化的脚本程序设计语言。这种语言在万维网上应用广泛，它往往被称为JavaScript或JScript，但实际上后两者是ECMA-262标准的实现和扩展。）来访问SharePoint。

本书的中文版并没有附带配套CD，如果你需要第25、26章的代码，可以通过下面的链接下载原书的配套CD（由于在版权方面的考虑，其中删除了部分内容）。

经过“漫长”的等待之后，《Microsoft Office SharePoint Server 2007 管理员指南》终于可以在china-pub上预订了。

自从Microsoft Office SharePoint Server 2007发布以来，虽然已经有数本有关开发类的中文书籍面世，但还没有一本权威、全面的，专门讲述SharePoint管理的书籍在国内出现。本书的英文版原著《Microsoft Office SharePoint Server 2007 Administrator’s Companion》，是一本由Bill English和众多SharePoint MVP、SharePoint专家共同撰写的，由微软出版社出版的权威性Microsoft Office SharePoint Server 2007管理类书籍。我相信，将本书的中文版本介绍给国内的SharePoint社区，具有重要的意义。

Microsoft Office SharePoint Server 2007是一个复杂的平台级产品，在很多时候，SharePoint的扩展开发与管理配置很难明显的分开。也就是说，如果您是一位SharePoint开发人员，您肯定会发现在项目开发过程中，需要对SharePoint管理和配置有所了解。同样，如果您是一位SharePoint系统管理员，在进行日常系统维护或系统升级操作过程中，有时候也同样需要具备一定的开发知识。所以本书的读者群并非仅仅包含SharePoint系统管理员和网站管理员，同样也包含了SharePoint开发人员和架构师。如果不能对SharePoint的管理和配置有全面且深入的了解，开发人员和架构师很可能在项目开发过程中举步维艰。

下面是一些关于此书内容和面向群体的Q&A，如果您不知道是否应该购买此书，可以参考此Q&A。

Q：我是一名SharePoint系统/网站管理员，这本书是不是就是为我准备的？
A：没错。如果您的工作就是对整个SharePoint系统，或者某个SharePoint网站进行管理，那么绝对有必要购买这样一本全面、细致的书籍，作为您日常工作的参考。

Q：我是一名SharePonit开发人员，平时的工作主要是基于SharePoint进行Web应用的开发，我有必要看这本书吗？
A：绝对有必要。如果您不能清楚的了解SharePoint管理和配置的一些细节，很多时候甚至难以确定如何对SharePoint进行扩展开发。何况很多时候，SharePoint系统的配置与开发之间的界限，是非常模糊的。比如，编写一个Feature定义XML文件，到底算是配置工作？还是开发工作？我一直认为，一个好的SharePoint开发人员，绝对应该至少是一个合格的SharePoint管理员。

Q：我是整个实施团队的PM/Architect/Tech Lead，这本书对我有帮助吗？
A：在本书中，除了具体的管理和配置指导之外，还包含了大量的规划（Planning）方面的内容。在您对整个系统进行设计时，这些规划指南将帮助您确定整个系统的物理拓扑、逻辑结构、分类体系、容量设计、安全设计等等等等。没有这些良好的规划，要想成功的实施一个SharePoint系统，几乎是不可能的。所以此书中所包含的大量规划指南、最佳实践等内容，将有效的指导项目团队的架构师，完成和完善整个SharePoint系统的设计。

Q：这本书和其他SharePoint管理类书籍的区别是什么？
A：完整性。本书的英文原版是由众多SharePoint MVP所撰写，由MS Press出版所发行的一本“权威之作”。它的内容相当的完整，几乎覆盖了规划、安装、升级、日常管理、监控、备份、灾难恢复等方方面面，而且每个方面的内容都具备相当好的可操作性。

Q：我听说下个版本的SharePoint 2010就要出来了，我现在还买SharePoint 2007的管理书籍，有必要吗？
A：首先，SharePoint 2010预计的发布时间是在2010年上半年，就算它能在2010年5月份发布，离现在也还有9个月时间。其次，以SharePoint产品现在的定位和市场情况而言，大量企业已经（或正在）基于SharePoint 2007构建各种Web应用。这些已经构建好的，或是正在构建的应用系统，想必不会在SharePoint 2010发布时就立即升级。甚至SharePoint 2010正式发布之后，也不见得所有SharePoint新项目就全部会基于新版本构建。所以在现在这个时间点，就考虑这本书是否已经过时的问题，似乎尚早。

Q：本书的中文版翻译质量如何？
A：翻译质量总是一个具有争议性的话题。作为本书的主要译者，如果我说这本书的翻译质量很好，似乎有自卖自夸的嫌疑。但我可以肯定的告诉大家的是：(1)它的所有译者都是了解并精通SharePoint的技术人员；(2)除了很少量没有必要且不影响理解的插图之外，本书绝大部分的插图都已经更换为了中文版；(3)本书中几乎所有术语都对照SharePoint Server 2007中文版，进行了认真细致的参照翻译。

Q：如果有什么理由不让我买这本书，那会是什么？
A：售价太贵。我也没想到出版社会将定价定为￥128.00元（折后约为￥96.00元），我之前一直猜想定价只会在50左右。但由于定价权在出版社，所以我也只能接受并尊重。从译者的立场，我当然认为读者从此书中获得的价值远超定价，但作为购书人的您，肯定不一定做此想。:)

最后，我将此书前言部分的内容介绍复制在了后面，您可以点击这里查看。

最近自己的工作有了些许变化。从8月19号开始，我正式从微软公司辞职，并加入了HP公司GPASE（Global Practices & Application Services Engineering）部门。加入HP之后，我的工作仍然会围绕着SharePoint产品和技术（所以，我仍然是在SharePoint领域之中）。同时，我也将继续为社区贡献我的力量。

谢谢大家继续关注我的blog！

前两天，从infoq上看到了这篇"你吓着我了，MOSS"。嗯，实际上，我想说的是：这本来就是一个很容易被吓到的时代。

如果我在这里说，SharePoint是多么多么的易用，对开发人员多么多么的友好，那么一定会有不少曾经被SharePoint"摧残"过或是正在被它"摧残"的开发人员，想要跳进面前的电脑，然后沿着长长的网线冲到我面前，掐着我的脖子前后摇晃着喊道："你瞎掰你瞎掰你瞎掰..."所以，我只好承认，如果你开始学习SharePoint，最开始的一段时间很可能会是非常艰难的，甚至你需要花费相当长的时间，才能对SharePoint的全貌有一个清晰的了解。从这个角度来说，SharePoint确实很能吓到我们。

但是，在这个"最好的"也是"最坏的"时代，对于一个开发人员来说，还有什么是容易就能做到的呢？只需要学会Delphi就能搞定一切的时代，已经一去不复返了。如今要在开发人员这个行业生存下来，每个人都必须不断的阅读大量的内容，学习各种花样翻新的技术。想想看，即使只是做一个不算复杂的Web网站，你也需要了解CLR、C#、ASP.NET、HTML、CSS、JavaScript、ADO.NET、ORM、Linq、Flash/Silverlight、IIS...你每天都会从网络上看到各种新产品、新技术、新名词，而看起来似乎每一样你都应该去学习。不管你是在哪个平台上（.NET/Java/Mobile...）做开发，这种情况几乎难以避免。你总会发现，每次你觉得对一个东东有了比较深入的了解，它的下个版本似乎就快发布了。客户的要求越来越高，老板却希望你一个人搞定所有的问题，而你开发的系统却越变越复杂，你希望通过引入一个ABC类库或XYZ框架来简化遇到的问题，却很快发现它们会带来更多的复杂性，而你还需要把各种东东整合在一起。

我其实要说的是，好吧，即使你打定主意，不去碰SharePoint，那么不管你打算去碰什么，情况也不会好到哪里去。这就是我们所处的这个时代的现状，我们需要构建前所未有的庞大系统，我们会遇到前所未有的艰巨挑战，我们所使用的是前所未有的复杂工具，而我们需要自己成为前所未有的"强大"的程序员。如果我们不能让自己的神经变得前所未有的坚强，那我们就只能每天被吓到。:)

今天，微软“半公开”发布了SharePoint 2010 Technical Preview。这是第一个对外发布的SharePoint 2010测试版本，它将提供给TAP（技术预览计划）参与者和MVP等少数群体。如果您是上面所列出的群体中的一员，那么恭喜您，您应该能直接拿到SharePoint 2010 Technical Preview相关的安装文件、文档和其他资料。如果不是，那么请继续往下阅读…

SharePoint 2010相比2007，从我的感觉来说，并没有“革命性”的突破，但在各个方面都有不少增强和改进。Office Web Application肯定是一大亮点。通过SharePoint 2010，用户可以直接在浏览器中查看和编辑Word、Excel、PowerPoint文档。当然，在大家所关注的开发支持方面，也有了相当大的改进。Visual Studio 2010中将直接内置SharePoint项目模板。如果您现在正在开发SharePoint 2007的项目，那么建议使用VSeWSS 1.3，微软有计划发布将VSeWSS 1.3项目升级到2010项目的工具。 

在sharepoint.microsoft.com网站上，已经开始添加SharePoint 2010的内容，其中比较有用的包括：
■ SharePoint 2010 Overview视频
■ SharePoint 2010 for Developer视频
■ SharePoint 2010 for IT Pro视频

学习SharePoint 2010最好的方法，可能就是参加今年10月份在拉斯维加斯举行的SharePoint Conference 2009（简称SPC09），时间为10月19-22日。在SPC09中，将包含大量的有关SharePoint 2010的技术讲座。在参加完SPC09之后（10月23日），您还选择可以参加两个额外的各为期一整天的技术培训讲座：
■ SharePoint 2010 Developer Deep Dive：由Andrew Connell和Ted Pattison主讲
■ SharePoint Server 2010 Installation and Upgrade Workshop：由Todd Klindt和Shane Young主讲

当然，如果您没法参加SPC09，也可以follow它的twitter：twitter.com/SPConf。

在微软download网站上，可以下载一份有关SharePoint 2010的开发文档。里面包含了一个关于如何定制SharePoint 2010 Ribbon界面的白皮书，和一个没太多用处的chm文件。

最后是一点安慰：在今年的迟些时候，微软将发布SharePoint 2010的公开测试版本。SharePoint 2010的正式发布日期计划是在2010年上半年。

最近正好有个朋友问这个方面的问题，如何规划一个SharePoint系统的磁盘容量？如果不能在前期做系统规划（Planning）的时候，确定好所需的磁盘容量，那么就很可能遇到系统上线3个月之后，发现服务器磁盘不够用的尴尬情况发生。

在微软TechNet网站上，有一些相关的文档和白皮书，比如《Capacity Planning and Sizing for Microsoft SharePoint Products and Technologies》。但是如果你懒得阅读白皮书，那么我可以给出一些简要的参数，根据这些参数，你可以快速的估算出一个SharePoint系统所需要的大致磁盘容量。

1、首先，你需要估算出整个系统中将要存放的内容的总容量。如果整个系统的总容量会随着系统的运行而不断增加（很多时候确实如此），那么你就想想你希望整个系统在上线后多长时间之内不想再进行磁盘容量上的升级，然后估算出这段时间之内，系统所存放的内容的总容量。

比如，每个月，所有用户会上传大概10GB文档到SharePoint服务器上。如果你希望SharePoint系统在未来两年之内，不用考虑容量升级的问题，那么这两年内，SharePoint系统中将存放总共240GB的文档。

由于SharePoint 2007文档管理会有“版本控制”和“回收站”的功能，所以在你估算的时候，不要忘记估算这两个功能将要占用的磁盘容量。

比如，在整个系统中，如果你估算大概会有5%的文件会存放到启用了版本控制功能的文档库中（提示：通常，并非所有文件都会需要版本控制的功能，很多文件都是一次性完成，或是无需保留历史版本的，对于这个文件所在的文档库，应该谨慎的使用版本控制功能），并且通过文档库的设置，限制了最多只保留10个主要版本，每个主要版本最多只保留5个次要版本（提示：对于启用了文档版本的文档库，同样需要设置好最多的主要版本的次要版本，避免版本数量无谓的增加太多），那么对于上面算出的240GB文档，你就需要还要加上240GB * 5% * 10 * 5 = 600GB的容量。

这样，我们计算出来的总容量空间将是：240GB + 600 GB = 840GB。

2、由于SharePoint会将所有的网站内容都存储到SQL Server数据库中，对于整个系统的数据库，你要准备所有内容总容量再乘上1.2-1.5倍的空间，给到SQL Server数据库。

比如，对于在第一个步骤里面计算出来的内容总容量840GB，我们就要给SQL Server数据库准备840GB * 1.5 = 1.3TB的磁盘空间。

3、由于SharePoint里面的索引服务（Index Services）会为所有的内容创建索引文件，所以你还需要注意为索引文件准备足够的磁盘空间。索引文件会占用的磁盘空间，可以按照(内容总容量 * (5-12%)) * 3倍这个公式进行计算。

对于5-12%这个比例，需要按照SharePonit中所存储的内容类型来进行适当的调整。例如，对于文档类型的内容（.doc、.docx、.xls、.xlsx、.pdf等），索引文件所占用空间的比例肯定会要比图片文件要高。如果你的SharePoint系统中主要是存放文档类别的内容，那么你就要将这个比例适当的加大，也就是更接近12%。

比如，对于840GB的内容，如果这些只有一部分是文档类型，那么我们要为索引文件准备840GB * 8% * 3 = 200GB的空间。

注意，如果在你的SharePoint服务器场中，索引服务是运行在一台单独的索引服务器（Index Server）上，那么就要在索引服务器上准备这么大的磁盘空间。

4、如果在SharePoint服务器场中，查询服务（Query Services）不是与索引服务运行在同一台服务器上，由于SharePoint会自动将索引文件从索引服务器上复制到运行查询服务的服务器上，所以在所有运行了查询服务的服务器上，同样需要准备足够的磁盘空间，留给索引文件。要准备的磁盘空间容量，计算方法与索引文件的容量相同。

5、最后，为了防止在估算的时候过于乐观，而且你也有足够的预算，那么不妨将上面的所有计算结果再乘上1.5 - 3倍（倍数可以按照您手里的预算来决定，呵呵）。比如，为SQL Server数据库准备2TB的磁盘空间，为索引文件准备300GB的磁盘空间。

最后，介绍两个SharePoint容量规划工具。第一个是微软的SharePoint Capacity Planning Tool，这个工具依赖于System Center Capacity Planner 2007。根据我的使用经验，个人认为这个工具过于花哨，实用价值不太高。:)

第二个工具是HP ProLiant Sizer for Microsoft Office SharePoint Server 2007，它是HP公司发布的一个工具。我对此工具没有什么使用经验。

第6讲：SharePoint开发 - 模式与重构（涂曙光）

5月30日，我会参加SharePoint技术峰会，并贡献一个讲座：《SharePoint开发：模式与重构》（或者可以叫做《如何将模式应用到你的SharePoint程序，并重构它》）。这个讲座面向的对象是SharePoint Developer和Architect。

这次活动的详细信息，请参考www.msiw.net。活动地点在霄云路现代汽车大厦18楼，参与者不需要负担任何门票费用，但午餐似乎需要自己解决。:)

更新：我在峰会上使用的PPT，以及现场显示的Demo源码下载。

Windows SharePoint Services 3.0 SP2 下载
SharePoint Server 2007 SP2 下载

最近在忙着给出版社交《Microsoft Office SharePoint Server 2007 管理员指南》的翻译稿，所以实在没有时间写blog了。希望等过了这阵子之后，再写一些新的东西。

WSS 3.0和MOSS 2007都发布最新版本v1.5 SDK了。

WSS 3.0 SDK v1.5下载
MOSS 2007 SDK v1.5下载