在Sharepoint项目中究竟应该做哪类的开发?

说是在的,这是一个困扰我多年的问题。虽然我只是个关注系统方面的IW,不是Developer,但是基于我对实际需求的认识和对Sharepoint本身的了解,我还是经常思考这个问题,并且总是得不到答案。

从2007年真正参与第一个一个企业门户的项目,这个问题就开始困扰我。当时的项目团队开发能力应该说挺强,不过其实MOSS2007刚刚发布,公开的信息非常至少,因此真正基于其上的开发难度可想而知,因此当时的开发可以说是纯粹的.Net开发,基本和Sharepoint无任何关系,甚至都没有集成到MOSS2007中,完全是独立的一个Web应用。

当时我的观点十分明确,Sharepoint项目应该尽可能利用这项技术本身的功能,来解决客户的实际问题,即使需要开发,也要是在此项技术之上的功能的扩展。然而随着对MOSS2007的更深的了解,我发现要用MOSS2007本身的功能来解决实际问题,特别是国内客户的问题,还是有相当的困难。一般来讲,国内企业要上MOSS项目的话,其实最先需要解决的是办公自动化OA的问题,而OA中最基本的需求其实都包含了复杂的流程,这一点恰恰是MOSS2007的弱项,虽然已经支持了工作流,但是要真正使用工作流解决问题,开发的难度可不是一般的大。

由于自身十几年的企业工作的经历,加上多年的和企业客户打交道的经验,我对企业信息化的需求有一定的了解。就目前的MOSS2007版本而言,基于其上的开发很难有一个清晰的思路。关于这点,我曾多次向圈内专业的开发人士请教沟通。

基于国内的实际情况,项目一般对外观有一定的要求,因此多年来我一直在思考纯粹的外观展示方面的一些需求,并请人写了一些专门用来展示内容的一些webpart,说白了就是把一些门户网站上比较通用的标准的Web的展示效果,在MOSS2007进行实现,把MOSS2007的页面做的尽可能不象MOSS2007的页面,我认为这算是基于MOSS2007的一类开发。

再就是工作流的开发了,工作流的开发因需求差异较大,针对项目的工作流,通用性的可能性不大,而且开发的成本也会较高。

以上说的是项目的开发,还有一类是产品开发,就是指有开发能力的公司,在moss之上做出自己通用解决方案的开发了,如工作流的解决方案,图表的解决方案,这类开发不但要有敏锐的眼光,还要有足够强大的开发团队,这就不是一般的公司能够做的了。

 

你可能感兴趣的:(SharePoint)