我正在学习 SharePoint 和您可以部署的不同类型的解决方案。从我正在观看的培训来看，您似乎应该尽可能地使用沙盒解决方案。这是因为农场解决方案可能会把事情搞得一团糟。
但是，沙盒解决方案不支持我对 WebPart 执行的两项主要操作。这些是可视 WebPart 和 WebPart 通信。（第一个是不允许的，因为它需要访问文件系统，第二个是不允许的，因为它使用反射）。
在我看来，我的 WebParts 总是希望至少做其中一件事情。（不通信的 WebPart 并不是真正的模块化，是吗？）
我错过了重点还是沙盒解决方案是一个在实际代码中没有真正使用的“好主意”？
是的，我同意你的观点，沙盒解决方案非常严格。
但是，正是这种限制赋予了它们价值。由于限制，沙盒解决方案无法关闭农场（至少理论上是这样，有人可能会找到一种方法来做到这一点）。
这意味着您可以向更多用户开放以在场上部署事物。将事物部署到 SharePoint Online 也是一项要求。
沙盒解决方案更具限制性，这意味着开发更加繁琐，您必须围绕限制进行编程。这使得解决方案更加昂贵。因此，默认值应该是农场，除非您有充分的理由不使用它。
我认为这里的一些评论缺少沙盒解决方案的全部要点，出于多种原因，他们被故意赋予了一组减少的权限：a) 网站集管理员可以添加 SB 解决方案，因此他们不需要是场管理员更好的农场安全。b）您可以相信 SB 不会关闭服务器场，它们甚至不会在正常的 SharePoint 工作进程下运行，而是托管在自己的进程下，该进程充当主机以检查访问的资源是否是允许 SB 解决方案。c) 云即将到来，这个事实无可避免，当其他人托管您的 SharePoint 解决方案时，您真的认为您可以访问服务器场吗？
我认为从非开发人员的角度理解作为沙盒解决方案运行的影响很重要，毕竟您不会创建任何类型的自定义解决方案并期望客户授予您域级帐户来运行它，因此在创建时SharePoint 解决方案，请考虑在默认情况下以最少的权限运行您的解决方案，如果真的没有其他方法，请探索场解决方案。
这是来自 MS 的有用指南：
如果您的环境允许您安装场解决方案，那么是的，沙盒解决方案是限制性的，并且会阻止您做您想做的事情。
但是，如果您的环境不允许定期部署解决方案，例如共享主机和一些大型企业，那么它们就没有限制，因为没有它们，您根本无法使用自定义代码。
沙盒太可怕了，我完全不同意“正是这种限制赋予了它们价值”的说法。你不能在沙盒中做很多事情。1. 没有会话 2. 没有网络部件通信 3. 没有文件上传控件 4. 没有重定向...
它只会让事情变得非常痛苦。我们正在开发面向外部用户的企业应用程序，我的建议是，如果您考虑将沙盒用于这些目的，我会说为您的项目增加 150% 的时间来处理沙盒问题。
大多数人都在谈论好处，但所有好处并不是真正的好处..例如，即使单个沙箱应用程序代码引发未处理的异常......祝你好运，它会崩溃整个农场，并且跟踪问题是真实的恶梦。
如果你能远离沙盒