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

zyh3033

　　说是在的，这是一个困扰我多年的问题。虽然我只是个关注系统方面的IW，不是Developer，但是基于我对实际需求的认识和对Sharepoint本身的了解，我还是经常思考这个问题，并且总是得不到答案。
　　从2007年真正参与第一个一个企业门户的项目，这个问题就开始困扰我。当时的项目团队开发能力应该说挺强，不过其实MOSS2007刚刚发布，公开的信息非常至少，因此真正基于其上的开发难度可想而知，因此当时的开发可以说是纯粹的.Net开发，基本和Sharepoint无任何关系，甚至都没有集成到MOSS2007中，完全是独立的一个Web应用。
　　当时我的观点十分明确，Sharepoint项目应该尽可能利用这项技术本身的功能，来解决客户的实际问题，即使需要开发，也要是在此项技术之上的功能的扩展。然而随着对MOSS2007的更深的了解，我发现要用MOSS2007本身的功能来解决实际问题，特别是国内客户的问题，还是有相当的困难。一般来讲，国内企业要上MOSS项目的话，其实最先需要解决的是办公自动化OA的问题，而OA中最基本的需求其实都包含了复杂的流程，这一点恰恰是MOSS2007的弱项，虽然已经支持了工作流，但是要真正使用工作流解决问题，开发的难度可不是一般的大。
　　由于自身十几年的企业工作的经历，加上多年的和企业客户打交道的经验，我对企业信息化的需求有一定的了解。就目前的MOSS2007版本而言，基于其上的开发很难有一个清晰的思路。关于这点，我曾多次向圈内专业的开发人士请教沟通。
　　基于国内的实际情况，项目一般对外观有一定的要求，因此多年来我一直在思考纯粹的外观展示方面的一些需求，并请人写了一些专门用来展示内容的一些webpart，说白了就是把一些门户网站上比较通用的标准的Web的展示效果，在MOSS2007进行实现，把MOSS2007的页面做的尽可能不象MOSS2007的页面，我认为这算是基于MOSS2007的一类开发。
　　再就是工作流的开发了，工作流的开发因需求差异较大，针对项目的工作流，通用性的可能性不大，而且开发的成本也会较高。
　　以上说的是项目的开发，还有一类是产品开发，就是指有开发能力的公司，在moss之上做出自己通用解决方案的开发了，如工作流的解决方案，图表的解决方案，这类开发不但要有敏锐的眼光，还要有足够强大的开发团队，这就不是一般的公司能够做的了。