Хм... Заранее замечу, что особого практического значения данная статья не имеет, поэтому студенты, желающие научиться чем-то пользоваться, могут нажать Alt+F4 (или Ctrl+W). Студенты, желающие узнать, как работает SharePoint, могут продолжить прокрутку вниз.
В настоящее время я пишу книгу о разработке SharePoint 2010 с помощью базы знаний и случайно обнаружил этот метод во время изучения недавно добавленной объектной модели в 2010 году. Мы все знаем, что в 2003/2007 году метод GetItemById SPList использовался для получения элементов списка на основе идентификатора (Что, вы не слышали об этом методе? Тогда боюсь, вы не являетесь квалифицированным разработчиком SharePoint...). Имя этого нового добавленного метода — GetItemByIdSelectedFields (в дополнение к нему также добавляется метод GetItemByIdAllFields, но он полностью эквивалентен GetItemById, так что больше никакой ерунды. Определение метода следующее:
1: public SPListItem GetItemByIdSelectedFields (int id, поля params string[])
Когда я впервые увидел это, я сразу подумал о свойстве ViewFields SPQuery. При получении записи списка возвращаются только определенные указанные поля для повышения эффективности. Но когда я написал консольную программу для тестирования, я обнаружил, что это не то, что я себе представлял. Например, я написал (этот метод требует написания внутреннего имени):
1: элемент SPListItem = spList.GetItemByIdSelectedFields(1, «Название», «Создано»); 2: Console.WriteLine(item["Modified"]);
Эта программа на самом деле не сообщила об ошибке, и измененное значение вернулось нормально, поэтому я попробовал. На самом деле в пользовательском списке было 50 полей, значения которых возвращались нормально, но все элементы запроса, пользователи и группы пользователей были. возвращается нормально (на самом деле это по сути элемент поиска). Ни один не был возвращен.
Движимый любопытством (оно меня пока не может убить), я в Reflector посмотрел исходный код этого метода:
1: if(field == null) 2: { 3: throw new ArgumentNullException("fields"); 4: } 5: 6: StringBuilder builder = new StringBuilder(); 7: foreach (строка str в полях) 8: { 9: if (str != null) 10: { 11: builder.Append("<FieldRef Name="" + str + ""/>" 12: } 13: } 14: 15: foreach (SPField); поле в this.Fields) 16: { 17: bool flag = false; 18: foreach (строка str2 в полях) 19: { 20: if (str2 == field.InternalName) 21: { 22: flag = true; перерыв; 24: } 25: } 26: if (!flag && field.MustFetchByDefault) 27: { 28: builder.Append("<FieldRef Name=""); 29: builder.Append(field.InternalName); 30; : builder.Append(""/>"); 31: } 32: } 33: 34: return this.GetItemById(id, null, false, builder.ToString());
Что касается последнего GetItemById, то пока нет необходимости в нем углубляться. Просто знайте, что это перегрузка GetItemById, и ее цель — поиск элементов. Последний параметр ставит поля, которые необходимо получить, в виде CAML. .
foreach в строке 7 легко понять. Мы добавляем нужные поля, но foreach в строке 15 вначале немного сбивает с толку. Нужно ли нам добавлять и другие поля? А что такое MustFetchByDefault SPField? Копнем немного глубже и посмотрим:
1: внутренний bool MustFetchByDefault 2: { 3: get 4: { 5: string fieldAttributeValue = this.GetFieldAttributeValue("List"); 6: if(!string.IsNullOrEmpty(fieldAttributeValue) && 7: (fieldAttrbuteValue != GlobalList.Docs. ToString())) 8: { 9: вернуть ложь 10: } 11: вернуть истину 12: } 13: };
Как определить, нужно ли получить поле? Судя по атрибуту List поля, метод GetFieldAttributeValue больше не публикуется (в противном случае его можно подозревать в мошенничестве с количеством слов). Короче говоря, это поиск списка из узла Xml, аналогичного атрибуту SchemaXml (описание поля). ) свойств поля. Если он найден и это не GlobalList.Docs (какая-то особенная штука), то это поле не нужно. Другими словами, мне не нужно возвращать это поле пользователю.
Итак, какие поля имеют атрибуты List в SchemaXml? Поле со списком атрибутов? Проверьте товар! Ха, он действительно избегал всех элементов поиска. (Docs — это атрибут списка поля «путь», который может иметь особое происхождение)
Теперь мы знаем, почему все остальные поля включены, а поиск не включен. Но почему? Если мы что-то знаем о базе данных контента SharePoint, мы будем знать, что элемент запроса на самом деле хранит только значение идентификатора в таблице AllUserData в базе данных контента (но когда он извлекается с использованием объектной модели, он включает соответствующее поле элемент запроса), что означает, что если вы хотите вернуть значение элемента запроса, вам необходимо выполнить некоторые дополнительные операции с базой данных (например, найти элемент, к которому обращаются, вернуть значение соответствующего поля и объединить его в). «1 ;#Администратор» такой призрачный вид). Что еще более важно, если элемент поиска является многозначным, то сам элемент поиска хранится в другой таблице (AllUserDataJunctions), поэтому для его возврата требуется много усилий. Итак, в 2010 году была добавлена новая вещь. Если наш список содержит много элементов поиска, и на данный момент мы можем использовать только один или два из них (или вообще ни одного), кажется, что использование этого метода действительно может значительно улучшить . эффективность.