您如何组织您的sharepoint开发？

Question

我最近开始做很多sharepoint开发，我做过的一些事情我不喜欢直接使用sharepoint设计器来处理页面布局，列表定义，母版页等等。 从我的角度来看，我觉得它更有条理，可以在Visual Studio中完成所有工作。通过这种方式，您可以将每个解决方案连接到源控制数据库，并使用脚本轻松部署/撤消/升级。

我的想法是创建一个像这样的vs解决方案： 1.一个用于列表和内容类型定义。 2.一个用于webparts。 3.一个用于品牌推广

但也许这种方法有任何不足之处，您还在使用其他什么方法？

Answer 1

真正的答案是：它取决于。

我认为有一种组织Visual Studio解决方案或SharePoint解决方案包的最佳方法。最后，您需要找到最适合您组织的内容并继续使用。

我见过的唯一指导来自SharePoint Online文档：

  

如果开发团队正在设计需要10个以上WSP文件的解决方案，那么团队应重新考虑其架构。在单个部署窗口中管理和部署如此多的WSP文件很困难，并且由于SharePoint Online管理它的复杂性，该解决方案存在拒绝风险。

     

需要跟踪和管理的大量解决方案包（WSP文件）对部署提出了挑战。自定义中的解决方案包越多，无法正确安装某些内容的可能性越大，解决方案部署所需的时间越长，并且混合不兼容的解决方案包版本就越容易。我们建议客户仔细检查他们的部署计划，并将解决方案包的数量保持在项目所需的最小数量。请记住，解决方案包可以包含多个功能，因此没有必要为每个功能提供一个解决方案包。

我同意这一点。您似乎在概述3个Visual Studio解决方案和/或SharePoint解决方案包，以确定单个SharePoint解决方案包中的3个功能。

我倾向于为每个项目创建一个Visual Studio解决方案。对于一个非常大的项目，单个Visual Studio解决方案可能包含多个项目，其中每个项目都代表一个SharePoint解决方案包。

对于Farm解决方案，每个SharePoint解决方案包都将包含许多功能或应用程序相关的功能和文件。如果两个或多个SharePoint解决方案包共享共同功能，我会将这些共享功能放入单独的解决方案包中。

Sandbox解决方案往往比Farm解决方案小得多。虽然我的Farm解决方案通常代表一个应用程序，但我的Sandbox解决方案更专注于解决一个特定问题。因此，我的Sandbox解决方案通常只包含一个不依赖于其他自定义功能或解决方案的功能。

正如我在开始时所说，我不相信有一条硬性或快速的规则。它通常取决于特定开发团队的偏好和风格。在开始时尝试几种不同的方式，最终你会发现最适合你团队的方式。