为业务建模——MOSS的优势与劣势

虽然2010已经发布了，但是在没有SP *之前，还是不打算正是应用到项目中。相信任何一个明智的项目技术决策人员会同意这个说法。 

所以打算使用SharePoint的项目而言，WSS 3.0 或 MOSS 对于在运行和将要实施的项目，应该还是首倡之选。

虽然较SPS 2003有很大的改进，但WSS3、MOSS依然被许多技术人员视为Portal和OA的选项。对于更加复杂的ERP、PDM/PLM，总显得有些力不从心。ERP 我不是很熟悉，就PDM或PLM，宏观而言，复杂的产品结构、交错的关联关系、庞大的数据容量都给基于SharePoint的项目实施带来了很大困扰；从细节而言，譬如：缺少事务机制、无法建立结构基线版本、WSS3中虽然有Document Library, 但是它却没有文档的概念，只有文件的概念 (在PDM中，版本控制主要是针对文档而言的，文档在产品生命周期不同阶段有不同的含义，它最终会产生一个或多个实体文件。)

下图只是一个现实业务模型的冰山一角：

 

但SharePoint还是一个非常不错的平台 (WSS MOSS SP2+1个Hotfix后，还是相当稳定的)

开放性

SharePoint是开放的，Web Service、BDC、XML/XSLT；众多公开、易于理解的接口；EventHandler (其实只是被动的事件处理，自定义事件无法享受EventRceiverManager可注册、事件队列等优秀的EventBus机制), 使用Feature包装技术点，使之功能化，并部署至服务器场；ASP.NET、WCF、AJAX的直接支持；MasterPage对页面布局的灵活控制；对Office的天然整合自然不用多说。总而言之，只要你愿意，可以在充分利用其优势的情况下，将它改的“面目全非”，当然对它的改动必须是在充分理解了SharePoint庞大规则的基础之上。在SharePoint实施过程中，常常听到重写某某控件，重写某某页面的决策，这些决定太过轻率，并会导致不可测的后果。

可建模(标准化)

SharePoint提供了ContentType作为主要的建模机制，ContentType可定义：栏位(属性)、事件处理、新建编辑查看表单、绑定工作流等。 如果涉及多个项目，可以将模型应用到所有项目，实现项目管理、设计管理、生产管理的标准化。ContentType的可继承性也确保了个项目模型定制的个性化能力。但是由于Lookup字段类型能力比较弱，无法在建立模型时确定各业务对象类型之间的关系。而这个缺失的能力可以通过扩展开发来实现，在后面的章节会详细解释。

可定制

SharePoint提供的组件都是可以定制或定制开发的。举两个常见的例子：SharePoint中典型的两个WebPart，ListViewWebPart和ListFormWebPart。

ListViewWebPart: 许多开发人员一看是sealed，就认为难以扩展，难以实现想要的效果，其实不然，因为ListViewWebPart只是一个空壳，数据-HTML的转化实际上是靠VIEW CAML完成的，在SharePoint 2010版本中，则提供了更通用的标准语言XSLT来替代这个转化规则。在SharePoint 2007中，我们可以通过定义CAML实现我们想要的HTML效果，也可以注册Custom Action来添加操作，同样可以定义新的ToolBar，包括New菜单等等。这些都是在保留了ListViewWebPart本身能力基础之上的扩展。

ListFormWebPart: 这个就更加不用多说了，除了Custom Action之外，可以通过开发或定制ASCX用户空间，置入12 templates controltemplate下，实现自定义的风格。

在对WSS3, MOSS的优劣势进行简单分析后，我们回归主题——为业务建模

在许多与传统业务紧密相关的IT项目中，进行as - is 和 to-be分析后，可以进行业务层次的对象建模。在传统的开发模式中，最终会映射为关系数据库的数据表关系表和抽象的逻辑层；而在基于类似SharePoint这种对象型数据库，实施的项目时，由于它已经在关系型数据库中进行了进一步的基于对象的架构，所以只需要进行简单的转化和抽象，就可以直接对业务层次的对象进行系统建模。