#sharepoint #sharepoint-2010
#sharepoint #sharepoint-2010
Вопрос:
Почему в некоторых примерах SharePoint используется
using (SPSite site = new SPSite(SPContext.Current.Web.Url))
{
...
}
и не просто?
SPSite site = SPContext.Current.Web.Site;
...
Обновить
Я думаю, что я сузил вопрос до следующего:
Кажется, что мне не следует использовать SPContent.Current напрямую, если я не уверен, что мой код выполняется внутри SharePoint. Но когда это было бы неверно?
Комментарии:
1. Взгляните на аналогичный вопрос от меня: sharepoint.stackexchange.com/questions/20192 /…
2. В более крупных проектах иногда внешние утилиты не запускаются в SharePoint. Другим примером являются модульные тесты, которые также не выполняются в SharePoint. Если вы просто разрабатываете визуальные веб-части и не проводите модульное тестирование — ваш код выполняется на SP.
3. при частом использовании в коде, похоже, возникает проблема с производительностью при новом подходе SPSite / SPWeb
4. @moontear Мне было интересно: если я программирую HttpModule — выполняется ли он в SharePoint? Это было бы частью запроса и всего остального, но это скорее на уровне IIS / веб-приложения — просто интересно ваше мнение / наблюдение / etc
5. Тогда вы должны комментировать мой ответ, а не исходное сообщение 😉 — Поскольку SharePoint вмешивается в конвейер запросов IIS, я не уверен, будет ли SPContext вообще работать, определенно безопаснее создать свой собственный SPSite. Во всех «внешних» случаях вы не можете быть уверены, что у вас есть правильный SPContext (например, функции, когда вы активируете их через PowerShell, у вас нет контекста!), используйте маршрут вручную. Если вы не можете быть уверены, как выполняется ваш HttpModule… вы знаете, что делать.
Ответ №1:
Взгляните на документацию по рекомендациям по удалению объектов в SharePoint 2010 от Microsoft, однако существуют противоположные мнения.
Есть несколько ключевых выводов для проектов SharePoint:
- Всегда удаляйте свои объекты SPWeb / SPSite -> утечки памяти
- Используйте SPContext.Current… когда вы уверены, что ваш код выполняется в контексте SharePoint
- Модульные тесты означают отсутствие контекста Sharepoint
- Внешние утилиты означают отсутствие контекста Sharepoint
- Powershell означает отсутствие контекста SharePoint (например, активация функции с помощью feature receiver может завершиться неудачей)
- Не удаляйте SPContext.Current… но создайте свой собственный объект (снова
using)
У вас могут возникнуть проблемы с согласованностью с несколькими вашими SP . объектами.
В конце концов, в некоторых случаях SPSite site = SPContext.Current.Web.Site; все в порядке, но у вас нет контроля над этим site объектом — это может быть проблемой. Если вы выберете new SPSite(...) , у вас всегда будет ваш SPSite сайт, а не что-то, что SharePoint создал и управлял для вас.
Лично я почти всегда использую using структуру, чтобы впоследствии все объекты располагались должным образом. В качестве альтернативы я использую SPContext.Current.Web без удаления.
Ответ №2:
Это зависит от контекста, в котором выполняется ваш код. Например, вам нужно создать новый SPSite экземпляр, если вы работаете в RunWithElevatedPrivileges блоке.
Ответ №3:
Деннис Джи прав. Удаление SPSite / SPWeb / etc важно, но убедитесь, что вы не удаляете объекты, предоставленные вам API напрямую. Это тонко, но важно, иначе ваш ответ никогда не будет сгенерирован или даже вызовет ситуации прерывания потока. По моему опыту, если мне нужна быстрая информация о свойстве SPSite или SPWeb, которая, я уверен, доступна в пользовательском контексте (авторизованный пользователь content manager или анонимный), то использование SPContext.Current.* object отлично подходит. В противном случае используйте метод RunWithElevatedPriveleges для переноса вашего кода, и внутри этого лямбда-выражения будет следующий шаблон:
SPSecurity.RunWithElevatedPrivileges(() =>
{
using (SPSite site = new SPSite(SPContext.Current.Site.ID))
{
using (SPWeb web = site.OpenWeb(SPContext.Current.Web.ID))
{
// stuff goes here elevated
}
}
});