我只是在学习如何为 Sharepoint 开发应用程序。
据我所知，可以通过三种类型的方式集成到 Sharepoint：
这是正确和完整的还是我遗漏了什么？
【问题讨论】：
标签： sharepoint sharepoint-2010 sharepoint-2007
根据您的范围、要求等，有很多方法可以为 SharePoint 开发。我在 SP2007 领域的知识比 2010 年更多，我的回答反映了这一点。
JavaScript
使用内容编辑器 Web 部件，您可以自定义 SharePoint 的外观、与列表数据交互并使用 jQuery 和 SPServices 插件来制作一些有趣的 UI 效果。这些解决方案不需要打包和部署。
自定义内容类型
这些可以通过 SharePoint UI 创建或通过自定义 XML 文档定义并通过 WSP 部署。本质上，这些只是以某种逻辑方式相关的字段定义的集合。可以将内容类型添加到列表中，以使所有字段自动可用。此外，它们提供了一种在同一个列表中混合和匹配数据的便捷方式（想想汇总或备份列表数据），尽管我从未以这种方式使用过它们。
事件接收器
可以创建事件接收器来响应 SharePoint 中的特定事件。如果您将事件接收器附加到列表，您可以侦听并响应事件，例如以同步 (-ing) 方式添加、更新、删除的项目或附件 - 这样您就可以实现验证并取消操作 - 或异步 (-ed) - 在 SharePoint 处理完项目后进行一些后处理。事件接收器由处理触发事件的请求的前端 SharePoint 服务器处理。这不同于由场中恰好可用的任何服务器执行的计时器作业和工作流。
此外，事件接收器可以根据其类型附加到列表（适用于此 ID 类型的所有列表），或者它们可以与内容类型关联并以这种方式与列表关联（添加内容类型时）添加到列表中，事件接收器也添加了）。
特征接收器是一种特殊的事件接收器，它们响应特征 被激活或停用以做一些额外的工作。许多人将这种额外的工作称为特征装订，因为它可以让您按需执行额外的任务，而这些任务仅使用 XML 文档是无法完成的。
定时器工作
计时器作业是按计划运行的一段代码。它不像事件接收器那样在 W3WP 进程中执行，而是通过 TimerService 执行。因此，SPRequest 对象中缺少某些功能或值。与事件接收器相比，开发计时器作业更困难，而且在实践中更容易出错、更难调试等。
工作流程
可以使用 SharePoint Designer 或 Visual Studio 创建工作流。这些之间的主要区别是您在设计时可以使用的功能。 SharePoint Designer 工作流更容易创建和启动，但在 SharePoint 2007 中往往存在错误。此外，它们不容易跨环境打包和部署，而是直接与您创建它们的列表相关联（2007 年；2010 年有扩展功能，允许打包甚至迁移到 Visual Studio 以进行更复杂的自定义）。
使用 Visual Studio 可为您提供更多深度和功能，但与 Timer Jobs 一样，它们通常难以“正确”，并且它们也由 Timer Service 进程处理。
Web 部件
自定义 Web 部件与在 SharePoint 上下文中具有一些扩展功能的常规 ASP.NET Web 部件非常相似。您可以访问 SPRequest 对象，因此可以访问所有上下文信息（当前用户、当前列表/网站/站点等）来完成您的工作。您可以访问外部数据库、使用大多数 ASP.NET 控件等。
自定义 ASPX 页面
如果 Web 部件不足以满足您的需求，或者您想要控制整个页面，您可以创建支持 SharePoint 的网页。这些是用适当的 SharePoint 母版页修饰并部署到 hive LAYOUTS 目录的子目录中的标准 ASP.NET 页面。有了这个，您可以像使用 Web 部件一样访问当前请求状态，但您可以更好地控制整个页面呈现。
自定义网络应用程序
如果您需要独立的应用程序，您仍然可以利用 SharePoint 的身份验证和授权工具，而无需直接在其上下文中运行。为此，请创建一个 IIS Web 应用程序并将应用程序池标识设置为与 SharePoint 相同。或者，您可以在 SharePoint 应用程序池中创建一个虚拟目录，但通常不建议这样做。如果您想使用 SharePoint 对象模型，您仍将受限于使用 .NET Framework 2.0 运行时。这种设置似乎很少在现场使用，因为大多数时候您只需使用自定义 ASPX 页面或 Web 部件即可满足您的需求。
关于您的具体问题：
沙盒解决方案只是一种特殊类型的解决方案，它限制您的 Web 部件等可以访问的命名空间。例如，您的代码无法访问其权限区域之外的访问列表。它无法代表您发送电子邮件。您可以通过使用自定义权限集来增加您的权限，但这是一个高级主题。我只是想指出“沙盒解决方案”本身并不是一种类型，它只是描述了以前不存在的限制（SP 2007 GAC 部署的解决方案）。
关于您关于使用 SharePoint 对象模型的 MVC 应用程序的问题，就像我提到的那样，您仍然受限于在 .NET 2.0 运行时中运行。
编辑：我忘了（至少）还有一个选项！
列表服务/其他 ASMX 服务
SharePoint 具有许多 Web 服务，您可以使用这些服务与列表进行交互等。在这种情况下，您的应用程序可以使用您希望的任何技术（或运行时！）开发，只要它知道如何使用 ASMX 服务。可用的功能不如直接使用对象模型丰富（这就是我经常忘记考虑它的原因），但它确实允许您的代码与 SharePoint 环境本身更加分离。在 2010 年，客户服务有更多选项可以提供更强大的功能。
【讨论】：
要在 Visual Studio 中开发解决方案，您可以选择沙盒解决方案和农场解决方案。如果您使用的是 SharePoint 2013，那么您将有另一个更好的选择，即应用程序部件开发。
由于从 SharePoint 2013 开始弃用沙盒解决方案，我建议您不要使用沙盒解决方案。最好进行 App Part 开发。
【讨论】：