Shareoint缺点.docVIP

微软Sharepoint的一些缺点 关于SharePoint，它是在文档管理平台上构建起来的，加入简单工作流功能的web系统。它完全基于微软体系架构，好处是与Office结合紧密，缺点是兼容性不够，过分依赖微软运行环境。 Sharepoint的工作流，只支持简单的顺序操作逻辑。如果涉及到退回、分支、循环、会签等复杂应用，就必须借助Visual Studio，完全通过编码来实现。 如果需要编码，就需要掌握Windows WorkFlow Fundation, Web Part, ASP.NET, CAML, Infopath以及Windows Sharepoint Server等大量内容，而且相关中文资料很少，会造成极高的二次开发成本。 最后，Sharepoint还存在难以控制页面字段权限，性能瓶颈，以及不支持分页调整等一些硬伤，具体可参见下面资料。以下内容全部摘自网友评论。 关于性能： 上海新世界地产用Sharepoint失败，因为运行很慢,维护成本非常高 调试时注意两件事，一个是计算机需要很多RAM，第二是SharePoint运行很慢，要耐心。 “在企业层面上，还有一定的领域有待于进一步开发，例如，在备份、性能和归档方面，我希望借助于其它的供应商参与进来” Bryne说。 关于产品定位： Sharepoint的工作流可以配置简单的，但是遇到复杂的需要自己去写程序，当然这是可以解决一部分业务工作流，但不是长久之计。 可能有些人还不知道，SharePoint是一个在文档管理平台上构建起来的、基于Web的办公套件。 Sharepoint可以当一个门户、文档管理、一些简单的oa办公流程 “当你安装并实施了SharePoint以后，就可以有一些基本文件的共享，但它不适合于更为复杂的文档管理。管理文档需要复杂的企业分类或更为复杂的有规则的工作流，那么SharePoint就有点落后了”。 关于工作流： 采用SharePoint Designer设计工作流的优点是操作简单，无须编译和部署，缺点是只能实现顺序操作逻辑，无法实现退回等循环逻辑，审批界面自动生成，也无法实现一些复杂的操作。如果需要这些，必须通过Visual Studio编程实现。 第一种需求oa系统，完全可以使用sps的列表和文档库来开发，一般的公文流转和工作流都不需要编写代码。这种系统如果对数据处理比较大的话就不是很方便，例如，报销单据的业务，用列表可以很方便开发报销的业务模块，但如果客户提出统计某部门某段时间的报销费用，或者对部门进行成本核算(用到报销的数据)。像这类业务使用列表来处理就很不灵活了。一旦有这样的需求原来用列表设计的模块可能需要改动来适应这种复杂的需求。 SharePoint带给你的意外收获是你可以得到一份支出单以及不用供应商，很容易向你的经理汇报情况。这一点是好的。但是，你还需要一个NET开发者进入到系统里。千万不要对培训内部员工有过高的希望。 SharePoint的工作流可以说是非常的脆弱，如果想在SharePoint上实现中国式的文档流转，我估计头上的白头发又会增加不少。不知道微软是怎么搞的，SharePoint这么优秀的解决方案，但工作流设计真的太不入流了，至少不满足中国国情。 关于二次开发： 最近有一个项目是针对基于Windows Sharepoint Server, 并利用Microsoft Office Sharepoint Server2007和Design的开发和部署(其实我对这个项目是颇有微辞的, 首先对于这类技术的集成还没有掌握, 项目书上说是配置占70%以上, 其实不然以这样的要求显然开发占了70%以上). 并且我对这种Microsoft极度推崇的技术也是心存一些不满的. 首先它的内容更广一些,不仅设计了Windows WorkFlow Fundation, Web Part, ASP.NET 2.0, CAML, Infopath以及Windows Sharepoint Server等大量内容还有许多企业应用的概念. 并与Office系列产品有高度集成. 这对于一个开发人员来说需要掌握更多的技术特性. 其实光是精通其中两样已经是很不容易的一回事了. 基于它的二次开发难度较大, 并且许多默认提供用户的操作方式都不是传统的Web用户操作习惯. 说穿了只是Microsoft想要捆绑它的一整套产品销售, 卖给那些政府或者大型企业而已. 哎! 感叹做为开发人员, 不是每个项目都能选择让你使用你擅长的喜爱的技术. 问题在于微软产品的高度集成和依赖性，不仅给用户的应用成本带来了约束，而且还限制了微软协同系统在非微软主流用户范围内的推广；完全基于微软体系架构，具有完整的技术体系和可靠的应用保障，但同时也存在兼容性不够，过分依赖微软运行环境的缺点