SharePoint基础之三- WSS是一个开发平台

可以这样认为, WSS在某种程度上抢了专业软件开发人员的饭碗, 因为它让用户能够创建和定制化他们自己的网站. 仅仅几分钟, 一个用户就可以创建出一个WSS站点, 添加几个列表和文档库, 并且自定义站点的外观来满足某种个别商业上的需求. 一个一模一样的解决方案, 如果单纯使用ASP.NET来开发的话, 大概需要一个研发人员做上几个星期甚至几个月才能完成.

 

从另一个方面说, WSS为专业的研发人员提供了一个激动人心的研发机会. 因为WSS的架构和功能只能引导你走到一定的距离, 不久, 你就会发现你需要创建自定义的列表类型, 为Web Part, event handler, workflow一类的WSS组件书写自定义的代码, WSS作为一个开发平台来说, 最不可思议的便是一开始它就是本着发展优良扩展性的原则而建立的. WSS开发平台包括对象模型, web part framework, web services, 和站点创建模型, 这些一起为可伸缩功能的门户应用程序提供了基础架构.

 

定制化与开发

=============

在你刚刚开始使用WSS平台来设计软件的时候, 分清楚自定义和开发的区别很关键. WSS对于用户来讲是非常灵活的, 因为他被设计为高水平的定制化提供支持. 如同我们指出的, 你不再需要是一个研发人员, 也能创建一个复杂的, 高度功能化的站点.

 

一个老练的用户可以创建并定制化列表和文档库. 用户也能通过修改web part来定制化和个性化(personalize)他们的页面的外观. 高级用户甚至能够提供高效地商标式的结局方案, 他可以通过在SharePoint Designer中定制与SharePoint相关联的母板页和层叠样式表来做到这一点.

 

你应该记住, WSS通过修改内容数据库中的数据来保存所有站点的定制化信息. 不论你是创建新列表, 还是定制化一个已经存在的列表(添加列或者视图), 抑或是通过SharePoint Designer执行的任何种类的修改, 都是如此.

 

事实上, 在内容数据库中保存定制化的信息既是WSS的一个长处, 也是一个弱点. 说是长处, 是因为它为用户和站点管理员在临时的定制化操作上提供了如此之多的灵活性. 说是一项专业软件的弱点, 是因为这样的定制化的修改很难进行版本控制, 也很难再多个站点之间复制.

 

考虑一个典型的ASP.NET开发工程吧. 应用在你工作中的所有的源代码都存在与你开发及其的一个单独的文件夹中. 一旦你结束了站点的初始设计和实现, 你可以将所有的站点源文件添加到一个源代码控制管理系统中, 比如说Microsoft Visual SourceSafe. 这使得在站点部署到生产环境之后, 用户可以纪律化地控制部署和更新. 你还可以挑选一些修改到测试环境中, 在那里你的页面和代码会在推向生产环境之前被完整地测试.

 

作为一个研发者, 你需要问自己下面的问题: 对于定制化你如何指导源码管理控制? 你如何使得一个列表定义或者页面实例的定制化的修改, 可以从研发环境移动到测试环境,最后再转移到生产环境上? 你怎样使得在某一个站点里进行定制化修改之后, 在另外的100个不同的站点里重用你的修改? 很不幸, 这些问题都很难, 通常你会发现一个可能的解决方案带来的麻烦会很不值得.

 

幸运的是, 作为一个研发人员, 你可以在WSS定制化的基础架构的水平之上进行工作. 具体而言, 你可以使用底层的源文件来创建底层的诸如列表和页面模板的定义. 这些底层的源文件不存在于内容数据库中, 相反, 他们存在于Web前端服务器的文件系统中. 在这个层次上工作要稍微复杂些, 还有一个陡峭的学习曲线. 无论如何, 它能够使你围绕着源代码进行管理, 并且以更纪律化的方式来将页面和代码从研发环境迁移向生产环境. 这个方式也使得版本控制和代码重用在多个站点间, Web application间, 服务器场间的转移的实现成为可能.

 

对于定制化和研发, 我们使用如下的标准来区分.

WSS定制化是通过修改内容数据库中的数据, 来达到的对一个站点的更新, 通常是在浏览器中或在SharePoint Designer中完成. 站点定制化不需要触碰前端服务器.

WSS开发涉及到的文件必须被部署到前端服务器上的文件系统中. WSS开发包括创建页面模板, 列表定义, 还有创建编译好的组件的DLL, 组件包括Web part, eventhandler, 工作流模板. 这个层次上的WSS开发也叫做developing provisioning components.

 

记住, 开发中研发人员需要对前端服务拥有一定程度的权限, 因为需要向前端服务器中推入页面模板和程序集等文件. 如果你在一个你在WSS环境中工作, 而你没有权限去对前端服务器进行任何修改, 那么你就不能部署任何你的研发成果. 在这样的环境中, 你只能使用定制化的技术- 通过修改内容数据库中的内容来完成的技术.

 

尽管定制化提供给用户了很大的灵活性, 但是, 开发确是更加强大的. 创建重用的WSS解决方案, 研发无疑是更好的方式, 而且开发的方式还能为高负载的优化站点的响应时间和吞吐量.

 

SharePoint研发机会

==============

作为一个研发人员, 你有很多种不同的扩展WSS的途径. 一些WSS的页面类型允许你直接写后台的托管代码; 另一些则不能. 然而, 你可以在Web Part 和ASP.NET用户控件中写代码, 然后在那些不支持直接写后台代码的页面中应用这些组件.

 

WSS3.0的强化之处在于添加了对ASP.NET母版页和层叠样式表的支持. 这为你创建标志站点或者顶级管理提供了大量的控制方式. 还有对ASP.NET navigation provider框架的支持, 使得你可以在SharePoint中创建标准ASP.NET站点中的一样的任意类型的自定义导航结构.

 

你还可以开发许多可以在WSS站点中使用的自定义的组件. 这些组件包括ASP.NET服务器控件, web part, event handler, 自定义数据域类型, 自定义策略.

 

作为一个研发人员, 你还拥有控制如何在一个自定义的站点中存储数据的能力. WSS允许你定义自定义的列表类型和文档库, 给你控制哪些视图可以暴露给用户, 哪些列包含在列表或者文档库中.

 

WSS3.0添加了一个项革新, 叫做site column(网站栏). 网站栏是一个可以被重用的列定义, 可以在多个列表中使用. 网站栏定义了一个列的名称, 其下的数据域类型, 还有其他的特性比如默认值, 格式, 和合法性确认等. 一旦你定义了一个网站栏, 你就可以通过修改自定义列表和文档库的schema来重用他们. 一个显然的好处就是, 你可以在一个地方修改网站栏, 并且让你的修改在所有使用了这个网站栏的列表里生效.

 

WSS3.0还有一项强大的革新, 目标在内容存储上. 它叫做content type(内容类型). 一个内容类型是一个灵活的课重用的WSS类型定义, 它定义了他的数据列, 还有它在一个列表中, 或文档中, 或者是文档库中的行为. 比如说, 你可以为某个客户演示文档创建一个内容类型, 包括一系列独特的数据列, 一个event handler, 还有他自己的文档模板. 你还能为一个用户需求文档创建第二个内容类型, 包括一些数据列, 一个工作流, 和一个不同的文档模板. 然后你可以创建一个新的文档库, 并配置这个文档库同时支持这两个内容类型. 内容类型对于WSS3.0来时非常重要, 因为他提供了WSS2.0所不具备的在列表和文档库中支持混杂类型的内容的能力.

 

另一个很棒的开发机会是使用新的Office Open XML文档格式. 这项由Microsoft Office 2007引入的新技术提供给你在服务器端的自定义组件中(比如event handler或workflow), 生成或操纵Microsoft Office Word文件和Microsoft Office Excel文件的能力. 这种文档格式剔除了在服务器本地安装某个版本的微软Office应用程序的需要. 所有的一切都可以通过对服务器端的库的编程来做到, 这样的库提供了高度的可衡量性和健壮性.

 

扩展WSS3.0里最激动人心的方面之一就是工作流了. WSS是建立在微软的新技术Windows Workflow Foundation之上的, Windows Workflow Foundation是.NET Framework 3.0的一部分. WSS添加一个额外的, 建立在Windows Workflow Foundation之上的维度, WSS站点中的列表项和文档可以附着上一些商业逻辑了. WSS扩展了Windows Workflow Foundation的基本模型, 做法是把一个任务列表(SharePoint task list)和一个历史列表(SharePoint workflow history list)跟每一个workflow联系起来. 这增加了workflow的责任度和可靠度, 更加人性化, 比如说审核和批准文档的工作流.

 

WSS和MOSS都附带工作流, 安装之后就可以使用. WSS包括一个简单的为缓和和批准一类的东西准备的路由工作流. MOSS提供更复杂的工作流, 他们可以支持Web Content Management approval process这样的特性.

 

对于自定义工作流的创建, 代表着一个明显的扩展点, 开发人员可以利用这一点依靠WSS或MOSS创建商业解决方案. 除了对Visual Studio Extensions for the Windows Workflow Foundation的标准的支持之外, Office团队还提供了一个WSS特化的Workflow Software Development Kit (SDK), 还有一个workflow starter kit(初学者工具包), 包括为指定WSS站点创建自定义workflow的Visual Studio的工程模板.

 

安全和站点成员从属关系是另外的两个提供给开发人员的扩展标准WSS基础架构的机会. 之前版本的WSS是跟Windows账户和Microsoft Active Directory紧密相关的, 使得SharePoint技术对于面向因特网的站点来说不适用. 对于WSS3.0来说, 这不是问题了. ASP.NET 2.0 提供了新的authentication provider基础架构, SharePoint的用户认证新架构就是基于那之上.

 

如果你不想在Active Directory(活动目录)中保存WSS的用户账户, 你可以简单的创建或获取一个ASP.NET的认证提供程序, 改程序被设计为在另外的身份识别存储媒介中, 比如说SQL Server数据库. 这个架构的增强使得WSS3.0获得了更宽广的作为平台来创建面向因特网站点的适应能力.

 

比方说, asp.net带有表单认证提供程序, 允许你在SQL Server中保存用户账户. 这个authentication provider可以使用在WSS3.0的站点中. 你需要做的并不多, 就可以把你的WSS站点放到因特网上了, 允许未知用户注册成为站点的成员. ASP.NET2.0提供了一个方便的创建和保存用户账户的支持, 方便你管理用户账户, 甚至允许用户修改或重设他们的密码. 你可以像在ASP.NET的解决方案中应用编程技术一样, 在WSS3.0中应用来管理用户账户.