うーん...この記事には実用的な意味はあまりないので、使い方を知りたい学生は Alt + F4 (または Ctrl + W) を押してください。 SharePoint がどのように機能するかを知りたい学生は、引き続き下にスクロールしてください。
私は現在、KB を使用して SharePoint 2010 開発に関する本を執筆しています。2010 年に新しく追加されたオブジェクト モデルを研究しているときに偶然このメソッドを発見しました。 2003 年または 2007 年に、ID に基づいてリスト アイテムを取得するために SPList の GetItemById メソッドが使用されたことは誰もが知っています (何、このメソッドを聞いたことがないのですか? では、残念ながら、あなたは SharePoint 開発者の資格がありません...)。この新しく追加されたメソッドの名前は GetItemByIdSelectedFields です (これに付随して GetItemByIdAllFields メソッドも追加されますが、これは GetItemById と完全に同等なので、これ以上無意味なことはありません)。
1: public SPListItem GetItemByIdSelectedFields(int id, params string[] フィールド)
これを初めて見たとき、リスト エントリを取得するときに、効率を向上させるために特定の指定されたフィールドのみが返される、SPQuery の ViewFields プロパティをすぐに思い出しました。しかし、テストするためにコンソール プログラムを作成したところ、それが私が想像していたものではないことがわかりました。たとえば、次のように書きました (このメソッドでは内部名を記述する必要があります)。
1: SPListItem item = spList.GetItemByIdSelectedFields(1, "Title", "Created"); 2: Console.WriteLine(item["Modified"]);
このプログラムは実際にはエラーを報告せず、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 形式で配置することだけです。 。
7 行目の foreach は必要なフィールドを追加するのが簡単ですが、15 行目の foreach は最初は他のフィールドも追加する必要があるのでしょうか。 SPField の MustFetchByDefault とは何ですか?もう少し詳しく見てみましょう。
1: 内部ブール MustFetchByDefault 2: { 3: get 4: { 5: string fieldAttributeValue = this.GetFieldAttributeValue("List"); 6: if(!string.IsNullOrEmpty(fieldAttributeValue) && 7: (fieldAttrbuteValue != GlobalList.Docs. ToString())) 8: { 9: false を返します; 10: } 11: true を返します; 12: } 13: }
フィールドを取得する必要があるかどうかを判断するにはどうすればよいですか?フィールドの List 属性を判定することで、GetFieldAttributeValue メソッドは投稿されなくなります (そうしないと単語数を不正にしていると疑われます)。つまり、SchemaXml 属性 (フィールドの説明) と同様に Xml ノードから List を検索することになります。 ) フィールドのプロパティ。見つかった場合、それが GlobalList.Docs (特別なもの) ではない場合、このフィールドは必要ありません。つまり、このフィールドをユーザーに返す必要はありません。
それでは、SchemaXml ではどのフィールドに List 属性があるのでしょうか?属性のリストを含むフィールドですか?アイテムをチェックしてみてください！はー、本当に全ての検索項目を回避してくれました。 (Docs は「パス」フィールドの List 属性であり、何らかの特別な起源を持つ可能性があります)
これで、他のフィールドがすべて含まれ、ルックアップが含まれない理由がわかりました。しかし、なぜ？ SharePoint コンテンツ データベースについてある程度の知識があれば、クエリ アイテムは実際にはコンテンツ データベースの AllUserData テーブルに ID 値を格納するだけであることがわかります (ただし、オブジェクト モデルを使用して取り出される場合、クエリ アイテムには、つまり、クエリ項目の値を返したい場合は、追加のデータベース操作 (参照される項目を検索し、対応するフィールドの値を返し、それを組み立てるなど) を実行する必要があります。 「1 ;#管理者」このような幽霊のような表情）。さらに重要なのは、ルックアップ項目が複数値の場合、ルックアップ項目自体は別のテーブル (AllUserDataJunctions) に格納されるため、それを返すのに多大な労力がかかることです。 2010 年に新しい機能が追加されました。リストに多くの検索項目が含まれており、当面はそれらのうちの 1 つまたは 2 つだけを使用する (またはまったく使用しない) 場合、この方法を使用すると実際に大幅に改善できるようです。 。 効率。