Hmm... Izinkan saya menyatakan sebelumnya bahwa artikel ini tidak memiliki banyak arti praktis, jadi bagi pelajar yang ingin mengetahui cara menggunakan sesuatu dapat menekan Alt + F4 (atau Ctrl + W). Siswa yang ingin mengetahui cara kerja SharePoint dapat terus menggulir ke bawah.
Saat ini saya sedang menulis buku tentang pengembangan SharePoint 2010 dengan KB, dan saya tidak sengaja menemukan metode ini saat mempelajari model objek yang baru ditambahkan pada tahun 2010. Kita semua tahu bahwa pada tahun 2003/2007, metode GetItemById SPList digunakan untuk mendapatkan item daftar berdasarkan ID (Apa, pernahkah Anda mendengar metode ini? Kalau begitu, saya khawatir Anda bukan pengembang SharePoint yang memenuhi syarat...). Nama metode yang baru ditambahkan ini adalah GetItemByIdSelectedFields (metode GetItemByIdAllFields juga ditambahkan untuk menyertainya, tetapi ini sepenuhnya setara dengan GetItemById, jadi tidak ada lagi omong kosong).
1: SPListItem publik GetItemByIdSelectedFields (int id, params string[] bidang)
Ketika saya pertama kali melihat ini, saya langsung memikirkan properti ViewFields dari SPQuery. Saat mendapatkan entri daftar, hanya bidang tertentu yang dikembalikan untuk meningkatkan efisiensi. Tetapi ketika saya menulis program Konsol untuk menguji, saya menemukan bahwa itu tidak seperti yang saya bayangkan. Misalnya, saya menulis (metode ini memerlukan penulisan nama internal):
1: SPListItem item = spList.GetItemByIdSelectedFields(1, "Judul", "Dibuat"); 2: Console.WriteLine(item["Dimodifikasi"]);
Program ini sebenarnya tidak melaporkan kesalahan, dan nilai Modifikasi dikembalikan secara normal, jadi saya mencobanya. Sebenarnya ada 50 bidang dalam daftar khusus yang nilainya dikembalikan secara normal, tetapi semua item kueri, pengguna, dan grup pengguna dikembalikan. dikembalikan secara normal. (Sebenarnya, ini pada dasarnya adalah item pencarian) Tidak ada yang dikembalikan.
Didorong oleh rasa ingin tahu (belum bisa membunuh saya), saya Reflector melihat kode sumber metode ini:
1: if(field == null) 2: { 3: throw new ArgumentNullException("fields"); 4: } 5: 6: StringBuilder builder = new StringBuilder(); 9: if (str != null) 10: { 11: builder.Append("<FieldRef Name="" + str + ""/>"); bidang di this.Fields) 16: { 17: bool flag = false; 18: foreach (string str2 di bidang) 19: { 20: if (str2 == field.InternalName) 21: { 22: flag = true; break; 24: } 25: } 26: if (!flag && field.MustFetchByDefault) 27: { 28: pembangun.Append("<FieldRef Name=""); 29: pembangun.Append(field.InternalName); 30 : pembangun.Append(""/>"); 31: } 32: } 33: 34: kembalikan this.GetItemById(id, null, false, builder.ToString());
Mengenai GetItemById yang terakhir, tidak perlu mendalaminya untuk saat ini. Ketahuilah bahwa ini adalah kelebihan GetItemById, dan tujuannya adalah untuk menemukan item. Parameter terakhir menempatkan bidang yang perlu diperoleh dalam bentuk CAML .
Foreach pada baris 7 mudah dimengerti. Kita menambahkan field yang kita butuhkan; tetapi foreach pada baris 15 agak membingungkan di awal. Apakah kita perlu menambahkan field lain juga? Dan apa MustFetchByDefault dari SPField? Mari kita gali lebih dalam dan lihat:
1: bool internal MustFetchByDefault 2: { 3: dapatkan 4: { 5: string fieldAttributeValue = this.GetFieldAttributeValue("List"); 6: if(!string.IsNullOrEmpty(fieldAttributeValue) && 7: (fieldAttrbuteValue != GlobalList.Docs. ToString())) 8: { 9: mengembalikan salah; 10: } 11: mengembalikan benar;
Bagaimana cara menentukan apakah suatu bidang perlu diambil? Dengan menilai atribut Daftar dari bidang tersebut, metode GetFieldAttributeValue tidak lagi diposting (jika tidak maka dicurigai melakukan kecurangan dalam jumlah kata). Singkatnya, metode ini adalah untuk menemukan Daftar dari node Xml yang mirip dengan atribut SchemaXml (deskripsi bidang ) dari properti Lapangan. Jika ditemukan dan bukan GlobalList.Docs (hal khusus), maka bidang ini tidak diperlukan.
Jadi bidang apa yang memiliki atribut Daftar di SchemaXml? Bidang dengan daftar atribut? Lihat barangnya! Ha, itu benar-benar menghindari semua item pencarian. (Dokumen adalah atribut Daftar dari bidang "jalur", yang mungkin memiliki asal khusus)
Sekarang kita tahu mengapa semua bidang lainnya disertakan dan pencarian tidak disertakan. Tapi kenapa? Jika kita mengetahui sesuatu tentang database konten SharePoint, kita akan mengetahui bahwa item kueri sebenarnya hanya menyimpan nilai ID dalam tabel AllUserData di database konten (tetapi ketika dikeluarkan menggunakan model objek, item tersebut menyertakan bidang terkait dari database konten SharePoint. item kueri.konten), yang berarti bahwa jika Anda ingin mengembalikan nilai item kueri, Anda perlu melakukan beberapa operasi database tambahan (seperti menemukan item yang sedang dikonsultasikan, mengembalikan nilai bidang terkait, dan menyusunnya menjadi "1 ;#Administrator" tampilan hantu seperti ini). Lebih penting lagi, jika item pencarian bersifat multi-nilai, maka item pencarian itu sendiri disimpan di tabel lain (AllUserDataJunctions), sehingga memerlukan banyak upaya untuk mengembalikannya. Jadi ada hal baru yang ditambahkan di tahun 2010. Jika daftar kami berisi banyak item pencarian, dan kami mungkin hanya menggunakan satu atau dua di antaranya (atau tidak sama sekali) untuk saat ini, tampaknya menggunakan metode ini memang dapat meningkatkan banyak hal. .efisiensi.