共享点编程有多好/不好？
我今天获得了一份工作机会，担任SharePoint开发人员。 我的一位朋友告诉我，共享点是一个大混乱，而不是我想要做的事情。
你在使用SharePoint方面有哪些经验/想法？
我打算在这里逆转一下这个趋势。 我将SharePoint视为一个开发平台 – 简单明了。 它利用其他技术，如IIS，ASP.NET，SQL Server和Windows Workflow，所以我不必重新发明轮子。 它让我专注于解决业务问题，而不用担心pipe道和系统级代码。
不要误会我的意思，SharePoint确实带着包袱，但是如果你想解决真实世界的商业问题而不仅仅是代码，那么它有很多东西可以提供。 我一直对WSSv3平台的丰富性感到惊叹 – 这是免费的。
如果您想与Microsoft技术保持一致，那么您需要意识到SharePoint在这里将保持并将继续变得更好，变得更加平常。 目前的版本（v3 – WSSv3 / MOSS 2007）缺乏AJAX，社交networking和其他function/技术。 v4版本即将到来，必将在这些领域进行改进。
关于我在这个post中读到的一些底片：
-
我已经编写了使用AJAX工具包生活在SharePoint中的Web部件，所以也有我的同事。 一个同事对Silverlight Web部件非常活跃。
-
是的，你确实倾向于在Windows Server 2003/2008上开发。 这并不妨碍我，我不花很多时间安装和configuration。 我有时使用虚拟机进行开发环境，并且认为有时会是一种痛苦。
然而，我所能做的是configuration一些东西而不是开发。 授权，完成; 供应，完成; 行级安全，完成; 基本的UI CRUD，完成; 部署到多个前端，完成; search，完成。 现在我有时间专注于解决业务问题。
如果你打算做SharePoint开发，你需要从右手开始。 我强烈build议在Microsoft Windows SharePoint Server 3.0内部深入了解开发人员可以/应该在SharePoint中执行的操作。
值得一提的是，我已经在开发超过20年的Unix和Windows上使用不同的语言和技术。 自从beta版以来，我一直关注SharePoint v3，并对我select的方向感到满意。
我对所有的积极回应感到惊讶。 让我问一下，你介意在代码中创build你的标记吗？ 就像在HtmlWriter.BeginTag（“br”）（或其他，对不知道HtmlWriter API）。 这被认为是创build可再发行的Web部件的最佳实践。
如何Ajax工具包？ 哎呀，closures限制。 由于标题中缺less文档types而无法使用。
而你的笔记本电脑运行的是Windows Server 2003，对吧？ 因为Sharepoint不会运行其他任何东西。
我了解人们捍卫他们的平台，但作为一个在Sharepoint中不得不做一些工作的人，但不再是…让我说为Sharepoint开发是我生命中最糟糕的发展经验。 现在，我已经非常谨慎地select了迄今的select，所以这不是最糟糕的经验，但它是在那里。 或者，换句话说，我宁愿在PHP工作比Sharepoint。
几年前，我的小网站简单地接受了SharePoint; 我们做了咨询，定制，培训等等。 确实，你得到了很多东西，我知道它有很大的改进。 但整体的经验是非常消极的，我们从来没有回头。
- 我们训练的用户绝对讨厌用户界面，不能修复那些错误的东西是非常令人沮丧的。
- 自定义Sharepoint的视觉呈现不是心灵的隐隐。 在微软写CSS的人无能为力。 我还有恶梦。
- 无论出于什么原因，他们不仅仅把它devise成一个花园式的networking应用程序，这使得开发环境成为巨大的痛苦。
总的来说，SharePoint在许多方面都没有达到它的承诺，这只是一个神秘的事情：看起来像没有脑子的东西需要各种定制开发。
我们已经回到为客户推出我们自己的解决scheme。 他们对这种安排感到高兴，我们也是如此。
不错============================= [=] ===不好
- 设置/pipe理/更新是一个痛苦
- 开发/debugging是一个痛苦
- 文档是一个笑话
Sharepoint是一个巨大的混乱。
- 生成的标记是我见过的最差的。
- 同样糟糕的CSS，在这个标记上花费很长时间。
- 上帝怜悯灵魂，必须重新devise或扩展共享点应用程序的客户端function。
- 整个平台飞行在好的build筑devise面前。
- 数据完整性是该平台的一个巨大问题，因为没有交易。
- 这个API令人惊讶地发现了错误，并且在使用这个API之后不会花费一个小时就会遇到一些错误，这些错误会让你在网上冲刷，并进一步加剧数据完整性问题。
- 适当的unit testing在平台上很难做到。
- 这个平台很大，挤满了“一切”，但是Sharepoint却做得不好。 你可以很容易地find其他框架或平台，更好地完成这项工作，将会更适合你或你的客户的要求。
- 学习曲线陡峭，如果平台的文档（特别是API）是好的，那就好了。
- 浏览器兼容性，Sharepoint只有IE浏览器（归因于其可怕的标记，CSS和JavaScript）。
不得不说，平台赚钱，而更多的是赚钱计划。 在Sharepoint开发人员的技能是罕见的，具有这些技能的人得到很好的支付。 客户通过自己的牙齿为Sharepoint定制开发和开发公司付出代价，因此尽最大努力说服客户，Sharepoint是一切的完美契合。
我的意见是，Sharepoint不是一个开发平台，而是一个赚钱平台。
编辑：我也忘了添加11.它的资源猪像你以前见过的任何东西。
我发现SharePoint最大的挫折，即使是最新版本，也是对文档缺乏关注。 有太多的logging不好的API调用。 我可以从发布这个答案中感受到我的血压上升。
自从2003年testing版本以来，我也喜欢Kirk，也喜欢它。 你当然可以总是希望有更好的想法 – 但我想你可以说几乎所有的企业产品。 对我而言，在SharePoint平台之上构build解决scheme时，积极因素远远超过了消极因素。
让我作为一个开发人员与我分享我的前5名好东西和前5名有关SharePoint的坏事情：
有关SharePoint的五大优点
- 这是一个综合性的平台。 使得开发和部署全function，标准化，可扩展和高可用性的Web解决scheme（如企业内联网和外联网）变得非常快。
- 它有巨大的势头。 微软继续改进，每一个版本都变得越来越好，社区也越来越好，在线资源也越来越好，越来越多的书出来了，许多免费的附加软件和好的第三方产品都出现了时间，也有很大的会议去。
- 非常模块化的平台，您可以将自己的东西打包到解决scheme，function，Web部件，模板，内容types等等。
- 它利用标准的Microsoft技术，如.NET，ASP.NET，IIS和SQL Server。 所以你不会陷入一个特定的技能集。
- 在目前的就业市场上，使用.NET + SharePoint技能要比.NET技能要好得多。 这就像说你有SAP的经验或者是一个BI专家。
和＃6：更多的女孩参与SharePoint项目（也许这应该是＃1 ;-)）。 女性通常会处理大型SharePoint项目中的许多较为柔和的方面，他们往往比男性更擅长。 一个成功的SharePoint项目不仅仅是编写一些Web部件，还要编写一些Web页面。 请阅读Paul Culmsee的“ 为什么SharePoint项目失败”的优秀系列。
关于SharePoint的五大坏事
- 陡峭的学习曲线。 成为一名优秀的SharePoint开发人员至less需要两年的时间 – 即使您已经擅长C＃和.NET。 你需要第一年才能理解平台中的所有概念，然后再来一年才能真正熟悉它们。
- 开发工具不足。 Visual Studio几乎不知道有关SharePoint的任何信息 – 但我听说这将会改变VS 2010的大好时机:-)
- 并不总是可以使用最新和最酷的.NETfunction。 它总是需要SharePoint几年才能从.NET平台团队采纳最新最好的东西。 想想Linq和AJAX吧。 我很好奇，看看/何时SharePoint 2010将支持.NET 4.0。
- 通常需要寻找解决方法来解决平台上古怪的问题/不一致之处。
- 更改API。 那么，至less这是一个从SPS 2003到MOSS 2007的痛苦。我希望过渡到SharePoint 2010将是一个更平稳的过程。
3个月前我对SharePoint一无所知。 从那时起，我不得不为公司的新支持网站创build一些自定义的Web部件，我必须同意你的朋友，这是一个大混乱。
起初，我对平台没有任何编码能做多less工作印象深刻。 但让我的东西正常工作令人沮丧。 我试图将之前编写的用户控件合并到一个常规的Web应用程序中，但是关键部分根本无法在SharePoint中工作，原因仍然不在我的面前。 我设法find一个解决方法，但在这个过程中失去了两个星期。
了解开发环境必须是实际运行SharePoint的机器也是令人沮丧的，该机器必须在Windows 2003/2008下运行。 我必须在现有的系统上build立一个虚拟机，这不是什么大问题，但是你必须克服一个障碍。
总而言之，对于你想要做的事情来说，这似乎过于困惑。 我同意在安装，configuration和部署上花费大量时间和实际开发的观点。 也许2010版本会更好。 这当然不是我期待与之合作的产品。
我是一个即将结束的SharePoint项目的3个月。
我花了我的时间，通过错误日志，试图找出为什么各种SharePoint组件不像MS所说的那样工作。 文档在开发行业中被许多人认为是“…我见过的最糟糕的”。 祝你好运在MS相关网站上find有用的东西。
许多“社交function”依赖于UPS（用户configuration文件服务），这是众所周知的错误和难以configuration; 谷歌它，你会看到。 在我的项目上，花了多个开发人员周和EE的博士学位才能使UPS工作。 所有这一切的Web服务！ 由于持续的稳定性问题，该公司最终聘请了一名宣称“我相信这个平台！”的SharePoint作者。 是，对。 我想知道他有多less钱可以这么说。 然而，不要忘记，每一个新的MS累积更新，UPS越来越接近可行，至less在开发环境。 从完全没有工作的初始版本开始，它已经走了很长一段路。
您将花大量时间configurationActive Directory，IIS，ForeFront身份pipe理服务，SQLServer和Server2008设置。 请记住，这些设置中的大部分都会相互冲突，因此准备花费大量时间在SharePoint博客上寻找解决方法。 事实上，大多数SharePoint博客都致力于解决方法和黑客，只是为了让SharePoint工作或至less将其提升到基本网站的function。 我认为一个具有预buildfunction的平台的全部重点是减less你的工作量，而不是增加它。 如果你想放置代码，而不是玩pipe理员或博客侦探，这不是你的平台。
正如其他地方提到的，开发要求是疯狂的 SharePoint Server（完整版本的产品）只能在Windows服务器上运行。 对我来说这意味着虚拟机。 8GB RAM是真正的最低限度，你可以逃脱。 我最终购买了核心i5,16GB和SSD来构build合理的快速开发环境。 这是networking开发，而不是video编辑。
如果您和/或您的团队足够幸运地在生产环境中获得稳定的SharePoint，最终用户将被视为5秒钟的页面加载，对几乎任何types的请求的响应时间都很慢，可能是最近最直观的用户界面计算历史。 SharePoint的主要吸引力之一是您可以通过添加各种types的Web部件或使用SharePoint Designer实际更改页面结构来即时编辑网页。 这样可以让经验丰富的开发人员陷入很多麻烦，所以我相信这个function针对的非技术用户将会死亡。 他们将会遇到相关ID错误的合唱，给他们一个非常有用的和内容丰富的GUID。
当涉及到这个烂摊子的时候，开发者和最终用户都放松了。 SharePoint唯一的好处是让我相信开源的必要性。
PS – 请不要攻击我的拼写或语法。 我不是英语专业。
SharePoint有时会令人沮丧。 根据微软的说法，这是一个“成熟的产品”，所以当你做错了什么，你会得到很好的错误，比如“发生错误”或“无法完成操作”。 CAML是需要很大的耐心的东西。 它的文档不是很好，你可以浪费大量的时间在一个愚蠢的语法错误。
总而言之，这是一个体面的平台，但这可能会导致你比同龄人更早白发。
我有体面的.net开发经验和3个月的SP，我的经验到目前为止：
好：
我认为SP对于简单数据模型的应用是很好的，最好是重读的。 一个巨大的优势是用户/pipe理员只能通过configuration实现。 随时更改数据结构，修改外观和感觉等。“我的书籍”类的一个很棒的平台。
不好：
但是SP有很多东西在你身上摔倒。 例如，当需要非平凡的逻辑时，特别是对于外键关系的聚合函数，很难工作。 当然，缺乏交易。 保持数据完整性可能成为一个问题。 当你考虑在一个特定的项目上工作时，要小心这个。
很less有编译时支持，大多数任务将包括通过名称作为string调用查找的资源。 它可以被认为是“灵活的”和“简单的”，但是对我的口味来说，它太过错误，会减慢发展速度。 当然，这不仅是SP的事情，但MVC /networkingforms似乎更容易推向强types的世界。
如果你喜欢托pipe的世界，那么处理绝大多数的SP是非托pipe代码的事实，给你像“HResult 8000072F”的例外，旁边没有堆栈跟踪提示你可能失败。
部署和错误再现性已经造成了相当多的挫折日子。 WSS需要整个机器本身，运行应用程序所需的文件分散在数据库，文件系统（通常是GAC）。 要有一个基本的项目分离，期望在许多不同的虚拟机上工作。
工具支持相当差（没有尝试过VS 2010）。 更好地期待与命令行和脚本交朋友。 期望debugging体验变慢。 unit testing很难做到..
我个人的结论是： SP有它的利基，但它不是一个.Net程序员可以享受的平台。 用户体验可能偶尔会有一些“WOW”，但开发者的体验却没有。 这可能是“陡峭的学习曲线”，但也许这只是它的方式。
这是一个（好？）的方式来支付账单….
SharePoint是第二版产品… v3将于2010年上市，是MS历史上增长最快的产品（据说）。 v2缺乏成熟性，这对于我们这些开发者来说绝对是一个需要解决的问题，但是有很多工具可以让开发更容易（stsdev，作为一个）。
如果你留在Windows领域，你会看到越来越多的东西。 这是一个强大的平台，它的未来看起来很有希望。
从开发人员的angular度来看，他们已经考虑过把它作为一种事后的想法，因为大多数基于Windows的应用程序都是这样的。 最终用户优先获胜，这是肯定的。
SharePoint的工作是具有挑战性和回报的，即使没有它的发展方面。 你正在影响整个组织，实际上帮助企业运行得更好。 发展方面会不时挫败你，但一切都趋于平衡。
取决于项目的运行方式，它会有很大的变化 – 如果您在SharePoint的devise中工作，则可以省去很多工作。 如果你的要求不符合要求，而客户不愿意妥协，那么可能会非常沮丧。
您也倾向于获得许多尚未正确设置的环境 – 即使是源代码pipe理和可重复部署等基本function也经常被忽略。 基础架构人员通常不了解SharePoint，因此您会遇到诸如无法将开发环境连接到networking的问题。
但是，如果有人参与了解他们在做什么，那么这些问题中的大多数都很容易解决。 一旦你经历了任何项目和环境问题，这是一个很好的平台。
官方文档并不是特别有用，但自从我开始使用该平台以来，可用的非官方文档和工具已经大大地提高了。
从其他答案中可以清楚地看到，SharePoint开发人员有很多挫败感。
给予的是：
- 是的，您必须在服务器产品Windows 2003或Windows 2008上进行开发
- 大量的发展信息来自不同质量的博客
- 该产品试图成为每个人的一切，但事实是，产品是如此之大，有专业领域的要求
对于开发人员来说，这绝对是一项技术。 开发者社区和微软提供的信息量在过去的两年中已经大幅增长。 有很多来自SharePoint的模式和实践团队的指导可以在这里find： http : //www.codeplex.com/spg
至于其他一些评论 – 这是增长最快的微软产品，在销售的许可证上测量，不一定在安装！ 是的，WSS 3.0免费提供的function相当惊人。
“SharePoint开发”可以涵盖的范围非常广泛。 它可能是通过Web浏览器和SharePoint Designer等工具驱动的纯Web内容开发。 或者沉迷于写自定义的ASP.NET Web部件，Windows Workflow，自定义的ASP.NET Web服务以及SharePoint托pipe的页面等等。
SharePoint附带的许多开箱即用的Web服务允许与其他系统集成，有些人可能会针对该API“SharePoint开发”调用编程。
我认为，总的来说，SharePoint的经验法则是表面上看来是一个包罗万象的产品，试图成为任何人的一切。 有时候，您不必深刻地了解表面，意识到如果没有重要的定制，平台将无法解决您的特定业务需求。 有时候，最后10％的function需要花费90％的时间！
这同时也是你最令人沮丧和最有意义的经历。 虽然薪酬（至less部分）以高薪的forms出现（与直接networking开发相比），但是这种挫折并不是无法用stackoverflow和Google来克服的。
自2003年以来，我一直在做SharePoint开发，以及“我开始讨厌讨厌！”的山谷。 总是被“DUDE，那真是太棒了！
如果您提供了SharePoint的入门级职位，我会心存感激。 你会得到在周围最热门的技术之一的在职培训。
如果您有Web开发背景，我认为您可能会因Sharepoint为开发人员缺乏灵活性而感到沮丧。 如果你以前有灵活性来写一些更接近于HTML的东西，那么被限制去思考“Web部件”，并不是很有趣。
另外，我发现，相对于常规的Web开发，花费在configuration/实现问题上的时间很多。
虽然你可以获得“开箱即用”的合理数量的function。
我很高兴地告诉你有一个积极的SharePoint编程经验。 我同意现成的masterpages和css是非常糟糕的，并且在API中缺less文档的时候可能会非常令人沮丧，但是如果您将SharePoint看作是开发框架，一个可以定制的有限产品。 我曾经在MS上读过一篇文章，将SharePoint描述为“模型粘土”，其开箱即用的模板仅仅是可以实现的“演示”。
我发现构build一个自定义的母版页非常容易和简单（例如，在头文件中使用适当的Doc Type去除可怕的BackCompat并启用CSS1Compat），或者让我的aspx页面带有代码隐藏或其他任何东西。 底线是 – 无论你可以在一个纯净的asp.net 2.0网站内做什么，你可以做同样的SharePoint，并从其可伸缩性，部署技术，API，权限模型，审计，文档存储系统，InfoPath集成，工作stream程，等等
我想这最终取决于你的观点：SharePoint是一个带有“演示”网站模板集合的开发平台，还是一个半有限的产品，允许你在这里和那里定制它？
我最初是一名ASP.NET开发人员，负责构buildWeb Content Management Systems并与Document Management Systems合作。 在这个领域，SharePoint是一个自然而然的进步，利用我已经在平台之上的技能。
我在去年做了一个介绍，可能有兴趣。
更多信息可以在这里find： http : //sharepointdevwiki.com/x/HYBfAQ
