转：http://bbs.tianya.cn/post-144-566491-1.shtml
微软Sharepoint的一些缺点（一）
微软Sharepoint的一些缺点
关于SharePoint，它是在文档管理平台上构建起来的，加入简单工作流功能的web系统。它完全基于微软体系架构，好处是与Office结合紧密，缺点是兼容性不够，过分依赖微软运行环境。
Sharepoint的工作流，只支持简单的顺序操作逻辑。如果涉及到退回、分支、循环、会签等复杂应用，就必须借助Visual Studio，完全通过编码来实现。
如果需要编码，就需要掌握Windows WorkFlow Fundation, Web Part, ASP.NET, CAML, Infopath以及Windows Sharepoint Server等大量内容，而且相关中文资料很少，会造成极高的二次开发成本。
最后，Sharepoint还存在难以控制页面字段权限，性能瓶颈，以及不支持分页调整等一些硬伤，具体可参见下面资料。以下内容全部摘自网友评论。
关于性能：
1. 上海新世界地产用Sharepoint失败，因为运行很慢,维护成本非常高
2. 调试时注意两件事，一个是计算机需要很多RAM，第二是SharePoint运行很慢，要耐心。
3. “在企业层面上，还有一定的领域有待于进一步开发，例如，在备份、性能和归档方面，我希望借助于其它的供应商参与进来” Bryne说。
关于产品定位：
1. Sharepoint的工作流可以配置简单的，但是遇到复杂的需要自己去写程序，当然这是可以解决一部分业务工作流，但不是长久之计。
2. 可能有些人还不知道，SharePoint是一个在文档管理平台上构建起来的、基于Web的办公套件。
3. Sharepoint可以当一个门户、文档管理、一些简单的oa办公流程
“当你安装并实施了SharePoint以后，就可以有一些基本文件的共享，但它不适合于更为复杂的文档管理。管理文档需要复杂的企业分类或更为复杂的有规则的工作流，那么SharePoint就有点落后了”。
关于工作流：
1. 采用SharePoint Designer设计工作流的优点是操作简单，无须编译和部署，缺点是只能实现顺序操作逻辑，无法实现退回等循环逻辑，审批界面自动生成，也无法实现一些复杂的操作。如果需要这些，必须通过Visual Studio编程实现。
2. 第一种需求oa系统，完全可以使用sps的列表和文档库来开发，一般的公文流转和工作流都不需要编写代码。这种系统如果对数据处理比较大的话就不是很方便，例如，报销单据的业务，用列表可以很方便开发报销的业务模块，但如果客户提出统计某部门某段时间的报销费用，或者对部门进行成本核算(用到报销的数据)。像这类业务使用列表来处理就很不灵活了。一旦有这样的需求原来用列表设计的模块可能需要改动来适应这种复杂的需求。
SharePoint带给你的意外收获是你可以得到一份支出单以及不用供应商，很容易向你的经理汇报情况。这一点是好的。但是，你还需要一个NET开发者进入到系统里。千万不要对培训内部员工有过高的希望。
3. SharePoint的工作流可以说是非常的脆弱，如果想在SharePoint上实现中国式的文档流转，我估计头上的白头发又会增加不少。不知道微软是怎么搞的，SharePoint这么优秀的解决方案，但工作流设计真的太不入流了，至少不满足中国国情。
关于SharePoint，它是在文档管理平台上构建起来的，加入简单工作流功能的web系统。它完全基于微软体系架构，好处是与Office结合紧密，缺点是兼容性不够，过分依赖微软运行环境。
Sharepoint的工作流，只支持简单的顺序操作逻辑。如果涉及到退回、分支、循环、会签等复杂应用，就必须借助Visual Studio，完全通过编码来实现。
如果需要编码，就需要掌握Windows WorkFlow Fundation, Web Part, ASP.NET, CAML, Infopath以及Windows Sharepoint Server等大量内容，而且相关中文资料很少，会造成极高的二次开发成本。
最后，Sharepoint还存在难以控制页面字段权限，性能瓶颈，以及不支持分页调整等一些硬伤，具体可参见下面资料。以下内容全部摘自网友评论。
关于性能：
1. 上海新世界地产用Sharepoint失败，因为运行很慢,维护成本非常高
2. 调试时注意两件事，一个是计算机需要很多RAM，第二是SharePoint运行很慢，要耐心。
3. “在企业层面上，还有一定的领域有待于进一步开发，例如，在备份、性能和归档方面，我希望借助于其它的供应商参与进来” Bryne说。
关于产品定位：
1. Sharepoint的工作流可以配置简单的，但是遇到复杂的需要自己去写程序，当然这是可以解决一部分业务工作流，但不是长久之计。
2. 可能有些人还不知道，SharePoint是一个在文档管理平台上构建起来的、基于Web的办公套件。
3. Sharepoint可以当一个门户、文档管理、一些简单的oa办公流程
“当你安装并实施了SharePoint以后，就可以有一些基本文件的共享，但它不适合于更为复杂的文档管理。管理文档需要复杂的企业分类或更为复杂的有规则的工作流，那么SharePoint就有点落后了”。
关于工作流：
1. 采用SharePoint Designer设计工作流的优点是操作简单，无须编译和部署，缺点是只能实现顺序操作逻辑，无法实现退回等循环逻辑，审批界面自动生成，也无法实现一些复杂的操作。如果需要这些，必须通过Visual Studio编程实现。
2. 第一种需求oa系统，完全可以使用sps的列表和文档库来开发，一般的公文流转和工作流都不需要编写代码。这种系统如果对数据处理比较大的话就不是很方便，例如，报销单据的业务，用列表可以很方便开发报销的业务模块，但如果客户提出统计某部门某段时间的报销费用，或者对部门进行成本核算(用到报销的数据)。像这类业务使用列表来处理就很不灵活了。一旦有这样的需求原来用列表设计的模块可能需要改动来适应这种复杂的需求。
SharePoint带给你的意外收获是你可以得到一份支出单以及不用供应商，很容易向你的经理汇报情况。这一点是好的。但是，你还需要一个NET开发者进入到系统里。千万不要对培训内部员工有过高的希望。
3. SharePoint的工作流可以说是非常的脆弱，如果想在SharePoint上实现中国式的文档流转，我估计头上的白头发又会增加不少。不知道微软是怎么搞的，SharePoint这么优秀的解决方案，但工作流设计真的太不入流了，至少不满足中国国情。
微软Sharepoint的一些缺点（二）
微软Sharepoint的一些缺点
关于二次开发：
1. 最近有一个项目是针对基于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想要捆绑它的一整套产品销售, 卖给那些*或者大型企业而已. 哎! 感叹做为开发人员, 不是每个项目都能选择让你使用你擅长的喜爱的技术.
2. 问题在于微软产品的高度集成和依赖性，不仅给用户的应用成本带来了约束，而且还限制了微软协同系统在非微软主流用户范围内的推广；完全基于微软体系架构，具有完整的技术体系和可靠的应用保障，但同时也存在兼容性不够，过分依赖微软运行环境的缺点。另外，由于操作系统可靠性及源代码不开放等问题，对于复杂的大型应用和要求很高的环境，应用会受到影响。
关于权限：
1. 在MOSS/Sharepoint 控制视图页面访问权限开发的问题，这些功能通过sharepoint已有功能是很难解决的
2. 在二次开发上，SharePoint webpart定制还是比较难，定制一个自己满意的webpart真的很困难，其中webpart的权限机制真的让人厌烦，这一点我深有体会。还有SharePoint的外观定制也非常困难，如果经验不太丰富的开发者很难定制出比较漂亮的界面，我想这和sharepoint定位有关，因为它主要是用来定制内部门户网站。还有sharepoint的用户是与NT域相结合，因此如果想用sharepoint来进行外部网站开发，只有采用匿名访问机制了。SharePoint Portal Server
2003的权限只能控制到区域，而不能控制到具体的文件和文件夹，在区域下面进行项目管理时，只有采取为具体项目建立子站点的方式，这样就让最终用户使用时感到很茫然。
一些具体的技术缺陷：
1. 如果使用SharePoint 2007作为文档管理平台，它很让人诟病的一点就是，SharePoint 2007将文件本身直接存储在SQL Server数据库之中。虽然Windows SharePoint Services 3.0 SP1增加了一个External BLOB Storage(EBS)接口，但是微软并没有提供实现，而是需要开发人员自己来实现它。
2. sharepoint的部分应用缺点:
(1) List分页
List的分页只支持“上一页”，“下一页”，并不支持分页的调整。这个不太适合国内的做法。
(2) List的导出功能
SharePoint的List支持导出功能，里面导出的Excel，多2个默认的字段，这个也还ok，但是仔细对导出功能进行研究，发现导出的当前视图的所有数据信息，即使你分页了，或者是做过筛选，导出的都是当前视图的所有数据信息。
(3) List视图信息的筛选
List视图非常灵活，也非常好用，但是给用户自己定义，这个用户就不太乐意了。视图的筛选信息支持很多，但是不支持用户和组类型包含当前用户。所以做定向通知的时候，遇到发给一个组，就需要开发实现了。
如果不在AllItems页面下的list WebPart 看不到视图的选项，只能使用当前的视图。
(4) List 之间的1：N的关系
如一个List存储学生的常用信息，一个List存储学生对应的成绩信息。这个时候实现可以通过查阅项进行，通过查阅项只能实现一个1：1的关系，而且还要选，没有太多实际的用处。我以前参考一些资料，实现了类似的功能，但是操作起来有点繁琐，需要分2步进行。第一步，填写个人信息。第二步，填写成绩信息。
(5) 文档库
文档库可以支持文件的上传，但是上传上去之后，才能对文档的属性信息进行修改。对于中国人的习惯应该是上传文档的同时，再填写文档的属性信息。
文档库不支持附件的上传，如果希望对一个文件进行附件的图片的描述，这个时候就没有什么好办法啦，只能通过查阅项来处理。
(6) 富文本字段
这是一个存在很大争议的字段，我在这里不也不多说。只说一些常见的问题：
a) 图片的上传
一般的富文本字段
通过填写图片的路径和描述，来实现图片的添加功能。如果要添加图片，必须先找一个地方进行的图片的上传。
(7) 发布类型的富文本字段
发布类型的富文本字段，比一般的富文本改进了很多，可以选择相应的图片，但是如果要上传一个图片，这个时候，就在弹出新的页面进行上传，上传完毕之后，需要关闭当前页面。
(8) 搜索
搜索功能是SharePoint中5大特点之一，但是SharePoint的搜索功能是通过爬网爬出来的，所以针对List的某些特定字段（大于1个）的搜索，基本上无能为力。这个功能可以通过现有一个SmartQuery控件进行解决。
(9) 导航
SharePoint的顶部导航能很灵活的进行添加和删除，但是我们在当前站点添加一个页面，并把这个页面添加在导航的时候，就会发现，点击页面的导航，激活状态还是首页。这个问题好像只能通过对样式的修改进行解决。
(10) 样式
List显示信息的样式不太符合中国人
整个SharePoint的样式，不太适合中国人的风格，基本上每个项目都会修改SharePoint站点的样式
(11) 应用模板
微软提供一些应用程序模板，基本在实际的项目中，基本上不能使用
(12) 权限
SharePoint中的list默认会继承整个网站集的权限，ListItem 默认会继承List 的权限。当SharePoint中的用户是以单个AD用户加入的，并赋予权限，这个时候，List 和ListItem的权限记录会对对应用户和网站赋予权限的组，导致数据量很大。如果List 和 ListItem 都很大（30-50个list），这个时候想删除用户基本上不太可能了。
如果不给用户和组赋予网站集的权限，当在一个List或ListItem 赋予了用户和组的权限，在网站上就会出现一条相应的记录。
(13) 数据的删除
如果一个List的数据信息到了10w，你删除这个站点，就删不了了。
用户权限在List中出现次数过多，也会导致用户无法删除。
如果想对整个基于sharepoint平台的网站实现多语言版，不敢说是奢望，至少我至今还没有找到比较好的解决办法。
总的说来，sharepoint只比较适合做知识门户的开发，前提是你不嫌它太贵，因为硬件和软件投资都比较大。
关于二次开发：
1. 最近有一个项目是针对基于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想要捆绑它的一整套产品销售, 卖给那些*或者大型企业而已. 哎! 感叹做为开发人员, 不是每个项目都能选择让你使用你擅长的喜爱的技术.
2. 问题在于微软产品的高度集成和依赖性，不仅给用户的应用成本带来了约束，而且还限制了微软协同系统在非微软主流用户范围内的推广；完全基于微软体系架构，具有完整的技术体系和可靠的应用保障，但同时也存在兼容性不够，过分依赖微软运行环境的缺点。另外，由于操作系统可靠性及源代码不开放等问题，对于复杂的大型应用和要求很高的环境，应用会受到影响。
关于权限：
1. 在MOSS/Sharepoint 控制视图页面访问权限开发的问题，这些功能通过sharepoint已有功能是很难解决的
2. 在二次开发上，SharePoint webpart定制还是比较难，定制一个自己满意的webpart真的很困难，其中webpart的权限机制真的让人厌烦，这一点我深有体会。还有SharePoint的外观定制也非常困难，如果经验不太丰富的开发者很难定制出比较漂亮的界面，我想这和sharepoint定位有关，因为它主要是用来定制内部门户网站。还有sharepoint的用户是与NT域相结合，因此如果想用sharepoint来进行外部网站开发，只有采用匿名访问机制了。SharePoint Portal Server
2003的权限只能控制到区域，而不能控制到具体的文件和文件夹，在区域下面进行项目管理时，只有采取为具体项目建立子站点的方式，这样就让最终用户使用时感到很茫然。
一些具体的技术缺陷：
1. 如果使用SharePoint 2007作为文档管理平台，它很让人诟病的一点就是，SharePoint 2007将文件本身直接存储在SQL Server数据库之中。虽然Windows SharePoint Services 3.0 SP1增加了一个External BLOB Storage(EBS)接口，但是微软并没有提供实现，而是需要开发人员自己来实现它。
2. sharepoint的部分应用缺点:
(1) List分页
List的分页只支持“上一页”，“下一页”，并不支持分页的调整。这个不太适合国内的做法。
(2) List的导出功能
SharePoint的List支持导出功能，里面导出的Excel，多2个默认的字段，这个也还ok，但是仔细对导出功能进行研究，发现导出的当前视图的所有数据信息，即使你分页了，或者是做过筛选，导出的都是当前视图的所有数据信息。
(3) List视图信息的筛选
List视图非常灵活，也非常好用，但是给用户自己定义，这个用户就不太乐意了。视图的筛选信息支持很多，但是不支持用户和组类型包含当前用户。所以做定向通知的时候，遇到发给一个组，就需要开发实现了。
如果不在AllItems页面下的list WebPart 看不到视图的选项，只能使用当前的视图。
(4) List 之间的1：N的关系
如一个List存储学生的常用信息，一个List存储学生对应的成绩信息。这个时候实现可以通过查阅项进行，通过查阅项只能实现一个1：1的关系，而且还要选，没有太多实际的用处。我以前参考一些资料，实现了类似的功能，但是操作起来有点繁琐，需要分2步进行。第一步，填写个人信息。第二步，填写成绩信息。
(5) 文档库
文档库可以支持文件的上传，但是上传上去之后，才能对文档的属性信息进行修改。对于中国人的习惯应该是上传文档的同时，再填写文档的属性信息。
文档库不支持附件的上传，如果希望对一个文件进行附件的图片的描述，这个时候就没有什么好办法啦，只能通过查阅项来处理。
(6) 富文本字段
这是一个存在很大争议的字段，我在这里不也不多说。只说一些常见的问题：
a) 图片的上传
一般的富文本字段
通过填写图片的路径和描述，来实现图片的添加功能。如果要添加图片，必须先找一个地方进行的图片的上传。
(7) 发布类型的富文本字段
发布类型的富文本字段，比一般的富文本改进了很多，可以选择相应的图片，但是如果要上传一个图片，这个时候，就在弹出新的页面进行上传，上传完毕之后，需要关闭当前页面。
(8) 搜索
搜索功能是SharePoint中5大特点之一，但是SharePoint的搜索功能是通过爬网爬出来的，所以针对List的某些特定字段（大于1个）的搜索，基本上无能为力。这个功能可以通过现有一个SmartQuery控件进行解决。
(9) 导航
SharePoint的顶部导航能很灵活的进行添加和删除，但是我们在当前站点添加一个页面，并把这个页面添加在导航的时候，就会发现，点击页面的导航，激活状态还是首页。这个问题好像只能通过对样式的修改进行解决。
(10) 样式
List显示信息的样式不太符合中国人
整个SharePoint的样式，不太适合中国人的风格，基本上每个项目都会修改SharePoint站点的样式
(11) 应用模板
微软提供一些应用程序模板，基本在实际的项目中，基本上不能使用
(12) 权限
SharePoint中的list默认会继承整个网站集的权限，ListItem 默认会继承List 的权限。当SharePoint中的用户是以单个AD用户加入的，并赋予权限，这个时候，List 和ListItem的权限记录会对对应用户和网站赋予权限的组，导致数据量很大。如果List 和 ListItem 都很大（30-50个list），这个时候想删除用户基本上不太可能了。
如果不给用户和组赋予网站集的权限，当在一个List或ListItem 赋予了用户和组的权限，在网站上就会出现一条相应的记录。
(13) 数据的删除
如果一个List的数据信息到了10w，你删除这个站点，就删不了了。
用户权限在List中出现次数过多，也会导致用户无法删除。
如果想对整个基于sharepoint平台的网站实现多语言版，不敢说是奢望，至少我至今还没有找到比较好的解决办法。
总的说来，sharepoint只比较适合做知识门户的开发，前提是你不嫌它太贵，因为硬件和软件投资都比较大。