常常地摆在我们开发人员的面前, 一方面是一堆随时可变的业务逻辑需求(比如：我们部门要建立一个共享和审批的文档系统, 或是我们公司要建一个文档存储中心) , 另一方面是一个似乎被Microsoft Demo得无所不能的MOSS系统, 但是有一个问题就是, 如果你要开发出一个产品或是一个解决方案, 如何在这两者间进行搭桥, 而这一点却似乎没有人帮助你。
该用什么，Excel Service?列表库?文档库? 工作流?
本文以ＭＯＳＳ为例，把规划业务系统划分成如下几个阶段：
一、业务层次划分
分析方法依然没有改变，“自顶向下”，“先考虑业务流程再转向ＩＴ系统”
现在，没有疑问了，我们选择了Moss，那么从整个开发方案入手，
一个独立的解决方案（比如：一个企业项目管理系统）＝＞一个ＭＯＳＳ网站集
各个功能分解（比如：企业项目文档管理、施工记录管理、工程进度管理）=＞三个业务网站。
模块分解（比如，文档管理分：合同管理、预算管理、进度款管理、企业内部请示、政府批件）＝＞文档或列表库
数据结构分析（比如：合同管理（合同号，名称，合同对象．．．．））＝＞ 网站栏或列表栏
业务流分析（比如：打内部请示－＞部门经理批示－＞老总批示－＞通过） ＝＞ 工作流模型
重要的一点，很多进行ＭＯＳＳ开发的开发者，认为ＭＯＳＳ面向业务的功能更强而不去做基本的模块分析表，数据结构表，业务流程图，这对于以后开发工作带来很大的随意性。
二、技术方案选择
MOSS并不是万能的，作为一个方便的平台，它却是万能的。从上面的分析结果会形成一系列的模块功能表、数据结构表、业务流程图。继续自顶向下：
先考虑模块－＞ 这要求对ＭＯＳＳ网站和整个服务器产品系列有一个整体的了解，从上面例子看，＂项目进度管理＂整个一个模块完全是Project Server的事情，并且做为业主方，并不太注意考虑项目下面子活动的情况。这个模块可以交给Project组完成了，做的只要做一个接口。其实ＭＯＳＳ也可以做一个轻量级的项目管理，它提供的甘氏图都是这方面很好工具，但是如果是整个项目组人参与其中，最好把Project做一个后台。前端以MOSS来展示。
再考虑功能 －＞ 这要示对ＭＯＳＳ库和列表非常熟悉，MOSS中主要有如下三个库类型：列表库、文档库、表单库。 选择哪种库是至关重要的事情，如果一但库类型选择错误，迁移数据还是比较麻烦的。因为字段错了，你可以更改和添加，库错了，直接影响到系统的功能。
１ 列表库，主要用于以记录为主，一条记录支持多个附件，在SPD中可以方便地定义数据视图。
２ 文档库，主要用于以文档为主，一条记录只支持一个文档，在SPD中可以方便定义属性的视图，也方便使用Office与部门同事协同作业。
３ 表单库，优化的表单界面丰富的可编程性，支持方便的属性提升和ＯＡ功能，但表单插入附件比较不方便。
它们是并行的关系，并不是任何一种情况，有都可以不加思索地考虑，能用列表就用列表，然后再考虑其它。
举个例子：
从制作“合同管理”业务流程图中，我们发现，客户对于合同管理有如下描述：“一个合同，要包含合同编号，合同金额，合同预算时间金额，合同签订人，办理部门．．．．．．一个合同有ＷＯＲＤ版的电子文件，也有PDF版的扫描件，有招标文件”
很明显，如果用文档库来处理，每一个文档都附加这样的信息会产品大量的“脏数据”，这样的情况只能使用“列表”，一个列表项就是一个合同记录，并且可以附加很多附件。
另一个系统，客户这样描述他的需求：“每天，都会固定地有十几个下级公司上报他的用气量，我希望在一个网页里看到今天所有的上报记录和情况说明和附件文档，填上批准值，一次性批准今天全部申请”
很明显，InfoPath的表单一次只能显示一条记录而不能显示当天全部的记录，当然我们可以通过自定义工作流，再定义一个“今日申请InfoPath 表单”一条记录包含另一个库中今天所有申请。然后再定义一个回写回作流。但是如果用“列表”或“文档库”处理就很方便，你可以在SPD中使用“多项目表单 DataView”，在筛选条件里，加上@Created>=Today()，就ＯＫ了。
继续考虑数据结构=＞
首先考虑数据流，如果每天只有十几条数据入库，我想完可以使用列表库，而不必使用Sql Server，每个结算年度也就不到一万条。使用工作流每年归档一次。但如果每次处理的数据都超过一万多条，建议使用Sql Server，比如项目管理要求管理到2万根管材的状态数据，可以前台使用InfoPath表单，提交到Sql Server，使用Moss 的 BDC，来处理Sql Server的查询。
然后就是字段，一般ＭＯＳＳ中的栏都可以满足要求，一些共有字段，建议首先定义为“网站栏”然后再是列表或库中的栏，系统会帮助程序员自动维护一些共有的栏。不能满足要求的，简单点可以使用Event hanlder搞定，复杂点使用CustomFieldType，一个字段可以使用多种自定义特性。
与数据库设计不同的是，如果你想开发简单点，数据冗余有时是必须的。比如在“合同预算”中客户要求按月统计。如果你在列表中加入一个计算栏“月份”，=FormatDateTime ([日期],"yyyy-MM")，这样就可以直接在页面加入“选项筛选部件”，不使用SPD的视图，开发出简单的按月查询页面。
最后，开发工作远不止业务逻辑那么多，还涉及报表，查询，系统日后维护，这些都是从这些基本的库和数据中延伸出来的，设计一个好的业务逻辑底层，是开发好系统最关键的部件。WSS ３SDK，是最重要的参考资料。做好这些工作，再看看MOSS 2007的SDK，才发现原来MOSS果真可以Do Everything 。
该用什么，Excel Service?列表库?文档库? 工作流?
本文以ＭＯＳＳ为例，把规划业务系统划分成如下几个阶段：
一、业务层次划分
分析方法依然没有改变，“自顶向下”，“先考虑业务流程再转向ＩＴ系统”
现在，没有疑问了，我们选择了Moss，那么从整个开发方案入手，
一个独立的解决方案（比如：一个企业项目管理系统）＝＞一个ＭＯＳＳ网站集
各个功能分解（比如：企业项目文档管理、施工记录管理、工程进度管理）=＞三个业务网站。
模块分解（比如，文档管理分：合同管理、预算管理、进度款管理、企业内部请示、政府批件）＝＞文档或列表库
数据结构分析（比如：合同管理（合同号，名称，合同对象．．．．））＝＞ 网站栏或列表栏
业务流分析（比如：打内部请示－＞部门经理批示－＞老总批示－＞通过） ＝＞ 工作流模型
重要的一点，很多进行ＭＯＳＳ开发的开发者，认为ＭＯＳＳ面向业务的功能更强而不去做基本的模块分析表，数据结构表，业务流程图，这对于以后开发工作带来很大的随意性。
二、技术方案选择
MOSS并不是万能的，作为一个方便的平台，它却是万能的。从上面的分析结果会形成一系列的模块功能表、数据结构表、业务流程图。继续自顶向下：
先考虑模块－＞ 这要求对ＭＯＳＳ网站和整个服务器产品系列有一个整体的了解，从上面例子看，＂项目进度管理＂整个一个模块完全是Project Server的事情，并且做为业主方，并不太注意考虑项目下面子活动的情况。这个模块可以交给Project组完成了，做的只要做一个接口。其实ＭＯＳＳ也可以做一个轻量级的项目管理，它提供的甘氏图都是这方面很好工具，但是如果是整个项目组人参与其中，最好把Project做一个后台。前端以MOSS来展示。
再考虑功能 －＞ 这要示对ＭＯＳＳ库和列表非常熟悉，MOSS中主要有如下三个库类型：列表库、文档库、表单库。 选择哪种库是至关重要的事情，如果一但库类型选择错误，迁移数据还是比较麻烦的。因为字段错了，你可以更改和添加，库错了，直接影响到系统的功能。
１ 列表库，主要用于以记录为主，一条记录支持多个附件，在SPD中可以方便地定义数据视图。
２ 文档库，主要用于以文档为主，一条记录只支持一个文档，在SPD中可以方便定义属性的视图，也方便使用Office与部门同事协同作业。
３ 表单库，优化的表单界面丰富的可编程性，支持方便的属性提升和ＯＡ功能，但表单插入附件比较不方便。
它们是并行的关系，并不是任何一种情况，有都可以不加思索地考虑，能用列表就用列表，然后再考虑其它。
举个例子：
从制作“合同管理”业务流程图中，我们发现，客户对于合同管理有如下描述：“一个合同，要包含合同编号，合同金额，合同预算时间金额，合同签订人，办理部门．．．．．．一个合同有ＷＯＲＤ版的电子文件，也有PDF版的扫描件，有招标文件”
很明显，如果用文档库来处理，每一个文档都附加这样的信息会产品大量的“脏数据”，这样的情况只能使用“列表”，一个列表项就是一个合同记录，并且可以附加很多附件。
另一个系统，客户这样描述他的需求：“每天，都会固定地有十几个下级公司上报他的用气量，我希望在一个网页里看到今天所有的上报记录和情况说明和附件文档，填上批准值，一次性批准今天全部申请”
很明显，InfoPath的表单一次只能显示一条记录而不能显示当天全部的记录，当然我们可以通过自定义工作流，再定义一个“今日申请InfoPath 表单”一条记录包含另一个库中今天所有申请。然后再定义一个回写回作流。但是如果用“列表”或“文档库”处理就很方便，你可以在SPD中使用“多项目表单 DataView”，在筛选条件里，加上@Created>=Today()，就ＯＫ了。
继续考虑数据结构=＞
首先考虑数据流，如果每天只有十几条数据入库，我想完可以使用列表库，而不必使用Sql Server，每个结算年度也就不到一万条。使用工作流每年归档一次。但如果每次处理的数据都超过一万多条，建议使用Sql Server，比如项目管理要求管理到2万根管材的状态数据，可以前台使用InfoPath表单，提交到Sql Server，使用Moss 的 BDC，来处理Sql Server的查询。
然后就是字段，一般ＭＯＳＳ中的栏都可以满足要求，一些共有字段，建议首先定义为“网站栏”然后再是列表或库中的栏，系统会帮助程序员自动维护一些共有的栏。不能满足要求的，简单点可以使用Event hanlder搞定，复杂点使用CustomFieldType，一个字段可以使用多种自定义特性。
与数据库设计不同的是，如果你想开发简单点，数据冗余有时是必须的。比如在“合同预算”中客户要求按月统计。如果你在列表中加入一个计算栏“月份”，=FormatDateTime ([日期],"yyyy-MM")，这样就可以直接在页面加入“选项筛选部件”，不使用SPD的视图，开发出简单的按月查询页面。
最后，开发工作远不止业务逻辑那么多，还涉及报表，查询，系统日后维护，这些都是从这些基本的库和数据中延伸出来的，设计一个好的业务逻辑底层，是开发好系统最关键的部件。WSS ３SDK，是最重要的参考资料。做好这些工作，再看看MOSS 2007的SDK，才发现原来MOSS果真可以Do Everything 。
文章来源：http://lickies.sharepoint.org.cn/Lists/Posts/Post.aspx?List=34201ce7%2Dcc0e%2D452a%2D949a%2Dffcf74a1780a&ID=51