Несколько советов о том как сделать код более надежным и устойчивым:
- Получайте списки только с помощью такой конструкции
web.GetList(SPUrlUtility.CombineUrl(web.Url, listUrl)
Получение по Title списка ненадежно, так как Title может быть изменен пользователем без вашего ведома.
- При получении значений полей элементов списка используйте Id поля или его StaticName.
listItem[FieldId] //Если вы деплоите это поле или это встроенное поле listItem[FiledStaticName] //Если поле нестандартное и не вы его деплоите
Обращение по Title поля ненадежно, так как Title может меняться.
- Для стандартных полей используйте классы SPBuiltInFieldId и Microsoft.SharePoint.Publishing.FieldId
- Для обращения к стандартным типам контента используйте SPBuiltInContentTypeId и Microsoft.SharePoint.Publishing.ContentTypeId
- Используйте класс Convert для получения типизированного значения поля
Convert.ToDateTime(listItem["Created"])
Для разных типов полей SharePoint может возвращать разные типы данных. Например числа могут возвращаться как строки. Кроме того Convert корректно обрабатывает null. Даже если у вас Required поле, то все равно может вернуться null по многим причинам.
- Добавление элементов в список
list.AddItem() //только так //list.Items.Add() - ТАК ДЕЛАТЬ НЕЛЬЗЯ
- Количество элементов в списке
list.ItemCount //Только так //list.Items.Count – ТАК ДЕЛАТЬ НЕЛЬЗЯ
- AllowDeletion
Используйте AllowDeletion=”false” для списков и полей, которые вы деплоите в своем решении
- Sealed
Используйте Sealed=”true” для полей и типов контента, которые вы деплоите в своем решении
- Количество элементов в результатах
Обязательно указывайте RowLimit свойство при получении элементов с помощью SPQuery или KeywordQuery
- Проверка активации фич
В своем коде обязательно проверяйте, что необходимые для работы фичи активированы на узле\коллекции.
- Деплой веб-части вместе со списками
Если вы создаете веб-часть, которая обращается к списку, в том же решении, то обязательно поместите в одну фичу уровня Site. Внутри веб-части получайте список с RootWeb (см пункт 1).
- Не использовать RunWithElevatedPriveleges
Используйте конструктор SPSite с SPUserToken. Передавайте SPUserToken.SystemAccount.
Использование RunWithElevatedPriveleges оправдано только когда вы хотите обратиться к веб-сервису\БД от имени учетной записи пула приложений.
И не стоит забывать, что работает данный метод только в контексте веб-приложения.
- Не модифицировать SPPersistedObject в контексте веб-приложений
Это просто не работает. Можно обойти, но не стоит.
Все объекты, унаследованные от SPPersistedObject, должны создаваться\изменяться в фичах уровня Farm и WebApplication или в задачах таймера.
- Не обращаться к ресурсам компьютера
Их просто может не быть. Даже если вы при активации фичи создаете все что необходимо, то новый сервер может быть введен в ферму без переактивации фич.
Это касается фалов, вне тех что деплоятся в решении, ключей реестра, event source в windows event log и другого.
- Не использовать параметры в web.config
Код SharePoint может быть запущен не только в веб-приложении, но и в timerjob, powershell, процессе-домене службы поиска или в любом коде на сервере.
Естественно не везде будет работать стандартный класс ConfigurationManager(WebConfigurationManager).
Если есть еще советы – пишите, обязательно дополним список.
