业务相关的SharePoint开发和维护常用方案

wangyan188

本文谈谈本文人对SharePoint中业务相关的开发/维护的一些感想和可行方案。

1、业务相关的SharePoint应用概述

一般来讲，SharePoint主要被用作企业级的KM Portal。当SPS只被用作KM的时候，其内置的集成到AD的人员管理、基于subarea、subsite、list、document library，bbs等built-in的组件可以比较自然的映射到企业现实中的人员、组织结构、资源、讨论等等。但是，现实中，也有不少基于SPS这个平台进行二次开发的非KM应用系统，这类系统中，由于不可避免地要涉及到很多业务相关的逻辑，使得SPS中built-in的这些组件不足以处理这些额外的业务逻辑，那么此时，可以有哪些方案来进行二次开发呢？

2、SharePoint二次开发方案

2.1 JavaScript + Custom Data View + SPS WebService

首先，如果业务逻辑比较简单的话，特别当数据处理和对现实和操作的look&feel，要求不是很复杂，并且，也并不十分介意在客户端暴露业务逻辑的话，直接通过FrontPage定制SPS中的页面，通过Custom Data View和SPS提供的Web Servise作为数据的读写接口，配合JavaScript来处理数据并负责定制的显示界面，通常就能够满足要求。

这种方案的好处是没有用到任何的外部资源，可以在线开发、部署和维护，也非常方便打包和迁移，因此，一般来讲是比较被推荐的方案。

2.2 External Web Service Site

如果，业务更复杂一些，特别对于数据的处理能力和安全性要求更高（不想把业务规则暴露在Client端），则相对于方案2.1，一个简单的办法是可以将对业务处理部分移到服务端，一种方案就是建立一个额外的Web Service站点，专门用以处理这类业务，并通过Web Service接口与SPS通讯。

这种方案新增了开发和维护一个附加的独立Web Service站点的负担，但是可以获得2.1中的绝大多数好处，并且获得了更强的数据处理能力和安全性。当然，这个额外的站点不必须基于.NET Framework，也可以部署在在任何的远程服务器。

2.3 External Web Application Site

方案2.2能够解决2.1的“在客户端暴露业务逻辑”的安全性问题，但是，不能解决“提供复杂的显示界面和输入验证”的问题，这个方案则考虑将“提供复杂的显示界面和输入验证”的能力转移到一个外部的Web Application去，嵌入原有的SPS站点去。Application和SPS则同样通过SPS Web Service进行通讯。

不过，这样做虽然能够解决“提供复杂的显示界面和输入验证”的问题，但是，却有可能对维护造成一些问题，主要是SPS站点的list和外部站点的一致性问题，因为，SPS中list的列可以自由定制，但是，如果业务和现实依赖一个外部站点的话，这种定制就被极大的限制了，因为，外部站点将不再能确定它要处理的某些资源是否还和设计时保持一致。但不管怎么说，只要合理的对定制进行规范，这也是一个可行的方案。

2.4 Custom Web Part

看到以上的三个方案，很多人可能就在奇怪怎么不说Web Part，呵呵，我这就说到。Web Part在SPS开发中，似乎处于一个比较尴尬的境地，虽然它的功能很强，理论上自定义的Web Part可以处理任意复杂的业务逻辑和显示效果。

但是在实际的开发中，却往往是最后一两个被考虑的方案，究其原因就是，最重要的就是Custom Web Part的部署麻烦，并且，牵一发而动全身，可能会影响到整个站点的其它部分的运行，一个小错误可能导致整个页面崩溃，而且，往往很多错误是设计时不能检测到的，安全性和操作权限也是个大问题，总之，列举缺点真的很容易，因为实在很多。还有是特别是不利于维护，如果要为已有的系统扩展附加功能或修改已有的错误，又会一次次的陷入部署、调式的泥潭。所以，Web Part方式往往在以上的方案不能解决问题时才被考虑。当然，从另一个角度来讲，如果部署、维护的成本相对较低，或业务逻辑和显示界面极其复杂的话，则也可能优先考虑Custom Web Part方案。

3、总结

综上所述，按照业务需求的复杂程度，从2.1到2.4的方案应该是可以满足绝大多数需求的，条件许可的话，一般来讲，应尽可能选择靠前的方案。

当然，对于任何的应用场景，都要具体问题具体分析，本文只是提出一些并不完全的建议，开发人员的经验和能力，已有的可重用的资源等等，往往同样能左右可种解决方案的选择！

//文章结束