SPSite site = new SPSite(SPContext.Current.Web.Url) vs SPContext.Current.Web.Site

Question

为什么一些SharePoint示例会使用

using (SPSite site = new SPSite(SPContext.Current.Web.Url))
{
    ...
}

而不仅仅是简单的？

SPSite site = SPContext.Current.Web.Site;
...

更新

我想我把问题的范围缩小到以下几个方面：

似乎我不应该直接使用SPContent.Current，除非我确信我的代码在SharePoint中运行。但什么时候才会不是这样呢？

Answer 1

看看微软关于2010年SharePoint中的对象处理的最佳实践文档，但是有对立观点。

对于SharePoint项目，有几个关键的方法：

• 始终释放您的 SPWeb / SPSite对象->内存泄漏
• 利用SPContext.Current..。当您确信代码在SharePoint上下文中运行时
  • 单元测试意味着没有Sharepoint上下文
  • 外部实用程序意味着没有Sharepoint上下文
  • Powershell意味着没有SharePoint上下文(例如，用功能接收器激活功能可能会失败)

​

• 不要处置SPContext.Current..。但是创建自己的对象(同样是using)

你可能有多个SP的具有一致性的问题。对象。

最后，在某些情况下，SPSite site = SPContext.Current.Web.Site;是可以的，但是您无法控制这个site对象--这可能是问题所在。如果您选择new SPSite(...)，您将始终拥有您的 SPSite，而不是SharePoint为您创建和管理的东西。

就我个人而言，我几乎总是倾向于使用using结构，这样所有的对象都会在事后得到适当的处理。或者，我使用SPContext.Current.Web而不进行处理。

Answer 2

这取决于代码运行的上下文。例如，如果在一个SPSite块中运行，则需要创建一个新的RunWithElevatedPrivileges实例。

Answer 3

丹尼斯·G是对的。配置SPSite/SPWeb/etc很重要，但要确保不直接释放API提供给您的对象。这很微妙，但很关键，否则您的响应将永远不会生成，甚至不会导致线程中止的情况。根据我的经验，如果我需要关于SPSite或SPWeb属性的快速信息，并且我确信用户上下文(内容管理器授权用户或匿名用户)可以使用这些信息，那么使用SPContext.Current.* object是很好的。否则，使用RunWithElevatedPriveleges方法包装代码，并且在该lambda内部有以下模式：

SPSecurity.RunWithElevatedPrivileges(() =>
{
  using (SPSite site = new SPSite(SPContext.Current.Site.ID))
  {
    using (SPWeb web = site.OpenWeb(SPContext.Current.Web.ID))
    {
     // stuff goes here elevated
    }
  }
});