흠... 이 글은 실질적인 의미가 별로 없다는 점을 미리 말씀드리자면, 사용법을 알고 싶은 학생들은 Alt + F4 (혹은 Ctrl + W)를 눌러도 됩니다. SharePoint 작동 방식을 알고 싶은 학생은 계속해서 아래로 스크롤할 수 있습니다.
현재 KB와 함께 SharePoint 2010 개발에 관한 책을 집필 중인데, 2010년에 새로 추가된 개체 모델을 연구하던 중 우연히 이 방법을 발견했습니다. 우리 모두는 2003/2007년에 SPList의 GetItemById 메서드가 ID를 기반으로 목록 항목을 가져오는 데 사용되었다는 것을 알고 있습니다. (이 방법에 대해 들어보신 적이 없으십니까? 그러면 유감스럽게도 귀하는 자격을 갖춘 SharePoint 개발자가 아닙니다...) 새로 추가된 이 메서드의 이름은 GetItemByIdSelectedFields입니다(GetItemByIdAllFields 메서드도 함께 추가되지만 이는 GetItemById와 완전히 동일하므로 더 이상 의미가 없습니다). 메서드 정의는 다음과 같습니다.
1: 공용 SPListItem GetItemByIdSelectedFields(int id, params string[] 필드)
처음 봤을 때 SPQuery의 ViewFields 속성이 바로 떠올랐습니다. 목록 항목을 가져올 때 지정된 특정 필드만 반환하여 효율성을 높입니다. 그런데 테스트를 위해 콘솔 프로그램을 작성해보니 제가 상상했던 것과는 달랐습니다. 예를 들어 다음과 같이 썼습니다(이 방법에는 내부 이름을 작성해야 합니다).
1: SPListItem item = spList.GetItemByIdSelectedFields(1, "Title", "Created") 2: Console.WriteLine(item["Modified"]);
이 프로그램은 실제로 오류를 보고하지 않았고 수정된 값도 정상적으로 반환되어 있어서 시도해 봤습니다. 실제로 Custom List에 값이 정상적으로 반환된 필드가 50개 있었는데, 쿼리 항목과 사용자, 사용자 그룹이 모두 되더군요. (실제로는 조회항목입니다.) 반환된 항목이 없습니다.
호기심에 이끌려(아직은 나를 죽일 수는 없습니다), 저는 Reflector가 이 메소드의 소스 코드를 살펴보았습니다:
1: if(field == null) 2: { 3: throw new ArgumentNullException("fields"); 4: } 5: 6: StringBuilder builder = new StringBuilder() 7: foreach(필드의 문자열 str) 9: if (str != null) 10: { 11: builder.Append("<FieldRef Name="" + str + ""/>") 12: } 13: } 14: 15: foreach (SPField field in this.Fields) 16: { 17: bool 플래그 = false; 18: foreach(필드의 문자열 str2) 19: { 20: if (str2 == field.InternalName) 21: { 22: 플래그 = true; break; 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 형식으로 가져와야 합니다. .
7행의 foreach는 필요한 필드를 추가하지만 처음에는 다른 필드도 추가해야 합니까? 그리고 SPField의 MustFetchByDefault는 무엇입니까? 조금 더 깊이 파고들어 살펴보겠습니다.
1: 내부 bool MustFetchByDefault 2: { 3: 가져오기 4: { 5: string fieldAttributeValue = this.GetFieldAttributeValue("List"); 6: if(!string.IsNullOrEmpty(fieldAttributeValue) && 7: (fieldAttrbuteValue != GlobalList.Docs. ToString())) 8: { 9: false를 반환합니다. 10: } 11: true를 반환합니다.
필드를 검색해야 하는지 여부를 어떻게 결정하나요? 필드의 List 속성을 판단하면 GetFieldAttributeValue 메서드가 더 이상 게시되지 않습니다(그렇지 않으면 단어 수에 대한 부정행위가 의심됨). 즉, SchemaXml 속성(필드 설명)과 유사한 List를 Xml 노드에서 찾는 것입니다. ) 필드 속성. 발견되었지만 GlobalList.Docs(특별한 것)가 아닌 경우에는 이 필드가 필요하지 않습니다. 즉, 이 필드를 사용자에게 반환할 필요가 없습니다.
그렇다면 SchemaXml에 List 속성이 있는 필드는 무엇입니까? 속성 목록이 있는 필드인가요? 아이템을 확인해보세요! 하 정말 검색항목을 다 피했네요. (Docs는 "경로" 필드의 목록 속성으로, 특별한 출처가 있을 수 있습니다)
이제 우리는 다른 모든 필드가 포함되고 조회가 포함되지 않는 이유를 알았습니다. 그런데 왜? SharePoint 콘텐츠 데이터베이스에 대해 알고 있다면 쿼리 항목이 실제로 콘텐츠 데이터베이스의 AllUserData 테이블에 ID 값만 저장한다는 사실을 알 수 있습니다(그러나 개체 모델을 사용하여 꺼내면 쿼리 항목의 해당 필드가 포함됩니다). 즉, 쿼리 항목의 값을 반환하려면 몇 가지 추가 데이터베이스 작업(예: 참조 중인 항목 찾기, 해당 필드의 값 반환 및 항목 조합)을 수행해야 합니다. "1 ;#Administrator" 이런 유령 같은 표정). 더 중요한 것은 조회 항목이 다중 값인 경우 조회 항목 자체가 다른 테이블(AllUserDataJunctions)에 저장되므로 이를 반환하는 데 많은 노력이 필요하다는 것입니다. 그래서 2010년에 새로운 것이 추가되었습니다. 목록에 많은 조회 항목이 포함되어 있고 당분간 그 중 한두 개만 사용하거나 전혀 사용하지 않을 경우 이 방법을 사용하면 실제로 많은 개선이 가능한 것 같습니다. . 효율성.