Halo, Habr! Kami melanjutkan serangkaian artikel eksperimental kami, dengan mengamati yang Anda dapat secara langsung mempengaruhi proses pembuatan game di UWP. Hari ini kita akan berbicara tentang pertanyaan "Di mana menyimpan data?" Itu terus-menerus muncul di jajaran pengembang. Bergabunglah bersama kami dan bagikan pemikiran Anda dalam komentar!
Saya memberikan lantai kepada penulis, Alexei Plotnikov .Dalam artikel sebelumnya, saya mengangkat masalah sinkronisasi data pengguna yang nyaman antar perangkat dan pertama-tama saya memecahkan masalah dengan identifikasi, namun ini adalah fraksi terkecil dari apa yang masih harus dilakukan untuk mencapai tujuan.
Masalah yang jauh lebih kompleks adalah caranya, dan yang paling penting, lokasi data pengguna dan, melalui upaya Microsoft, ketika mengajukan pertanyaan seperti itu, hal pertama yang terlintas dalam pikiran adalah
Microsoft Azure . Platform cloud Azure mencakup beragam layanan sehingga tampaknya tidak ada tugas yang tidak dapat diselesaikan dengan bantuannya. Apakah itu benar atau tidak, saya tidak bisa menilai, tetapi tugas saya pasti dalam kekuatan platform ini. Namun, hal pertama yang pertama.
Kita mulai dari yang kecil - apa itu cloud? Untuk pertama kalinya saya mendengar tentang cloud pada tahun 2012 dan kemudian frasa "komputasi awan" paling sering digunakan. Gagasan awal dari perhitungan tersebut adalah untuk mendistribusikan pekerjaan komputasi antara berbagai perangkat yang terpisah satu sama lain. Sangat mengesankan berbicara tentang masa depan, di mana bahkan tugas yang paling sulit akan diproses dalam beberapa saat karena fakta bahwa perhitungan akan didistribusikan di antara semua komputer di dunia.
Dalam praktiknya, semuanya bermuara pada pusat data yang tersebar di seluruh dunia dan memberikan daya komputasi mereka kepada konsumen, dan konsep awalnya hanyalah distribusi antara mesin di dalam pusat data dan antara pusat data itu sendiri (paling sering di wilayah yang sama).
Berdasarkan hal tersebut di atas, kita dapat mengasumsikan bahwa ketika Anda mendengar kata "cloud", Anda dapat melihatnya sebagai "hosting" yang lebih akrab, dengan satu-satunya perbedaan adalah bahwa kekuatan cloud dapat diperluas tanpa upaya tambahan dari pihak Anda.
Pertanyaan kedua yang mungkin Anda miliki adalah mengapa Azure? "Karena ini adalah artikel di blog Microsoft, maka penulis hanya akan berbicara tentang produk mereka" - Anda katakan, dan Anda akan salah. Motif untuk menggunakan Azure jauh lebih umum - karena ini adalah produk Microsoft, ia memiliki tingkat integrasi setinggi mungkin dengan produk mereka yang lain, dengan bantuan aplikasi saya sedang dikembangkan.
Namun, saya perhatikan bahwa perusahaan melakukan segala upaya untuk membuat penggunaan Azure menarik bagi pengembang untuk Android atau iOS. Nah, yang disebutkan terakhir, tetapi tidak sedikit, masalah adalah biaya menggunakan cloud. Karena saya pemegang langganan BizSpark, saya telah diberikan pinjaman bulanan untuk tas dengan bunga lebih dari cukup untuk memenuhi kebutuhan cloud saya, meskipun ketentuan yang disediakan secara gratis juga dapat mencakup sebagian besar kebutuhan pengembang swasta.
Sekarang mari kita beralih ke pemilihan langsung mekanisme sinkronisasi dan penyimpanan data. Saya tidak akan licik, sebagai orang yang belajar sendiri saya sering harus berurusan dengan teknologi yang saya tidak tahu sebelum saya mengenal UWP, saya memecahkan masalah yang sama menggunakan database SQL.
Namun, UWP tidak memiliki sarana untuk bekerja dengan DBMS SQL klasik, dan SQLite ditawarkan sebagai alternatif, dan, setelah memulai studinya, saya menemukan bahwa basis data seperti itu adalah built-in, yang cocok untuk penyimpanan yang nyaman dan penggunaan data lokal, tetapi sama sekali tidak cocok untuk penempatan data. dalam penyimpanan jarak jauh. Sudah dalam proses penulisan artikel ini, ketika teknologi yang tepat dipilih, saya menemukan salah satu solusi Azure di bidang pengembangan aplikasi mobile, yang memungkinkan Anda untuk menyinkronkan data dari tabel SQLite antar perangkat, tetapi setelah memikirkannya dengan seksama, saya tetap pada pilihan awal.
Omong-omong, membuat pilihan awal tidak sulit, karena Microsoft dengan sopan meminta daftar teknologi yang mungkin harus dihadapi oleh pengembang UWP. Dalam versi terbaru Visual Studio, saat membuat proyek UWP baru, Anda akan melihat halaman dengan rekomendasi untuk memulai, di mana salah satu tautan bertuliskan "Menambahkan Layanan yang Disarankan". Dengan mengklik tautan ini, tab "Sambungkan layanan" terbuka dan sudah ada di dalamnya kita melihat opsi "Penyimpanan awan dengan layanan penyimpanan Azure".
Intuition menyarankan bahwa inilah yang Anda butuhkan, jadi saya memutuskan untuk fokus pada studi mendalam tentang masalah ini dengan maksud untuk digunakan lebih lanjut dalam proyek ini.
Penyimpanan awan adalah seperangkat beberapa produk untuk tugas yang berbeda, yang dapat dibaca lebih lanjut di
sini , tetapi saya terutama tertarik pada penyimpanan tabel, yang ternyata adalah basis data NoSQL.
NoSQL adalah database bebas skema, yaitu, di mana tabel tidak perlu disusun sebelumnya. Bahkan, tabel dalam kasus ini hanyalah bagian dari jalan menuju apa yang disebut bagian, yang berarti bahwa satu tabel dapat berisi baris, misalnya, dengan tiga dan lima kolom sekaligus. Untuk sepenuhnya memahami fitur-fitur penyimpanan tabel, saya menyarankan Anda untuk membaca
manual dengan hati-hati, tetapi saya akan mempertimbangkan topik ini dari sudut pandang biasa saya, karena pada akhirnya materi ini ditujukan untuk pemula, siapa saya dalam topik ini.
Untuk memulainya, mari cari tahu cara membuat tabel NoSQL:1. Daftarkan akun Azure
gratis . Jika Anda memiliki langganan MSDN atau BizSpark dan sudah diaktifkan di Azure, maka Anda dapat melewati langkah ini. Akun gratis memberi Anda pinjaman $ 200 untuk bulan pertama dan kemudian akses gratis ke sejumlah sumber daya sebagian besar layanan Azure. Diterjemahkan ke dalam bahasa yang dapat dimengerti, semuanya dilakukan sedemikian rupa sehingga Anda tidak perlu membayar sampai produk Anda menghasilkan cukup untuk menutupi pengeluaran, belum lagi penggunaan Azure untuk pendidikan mandiri.
Tetapi bahkan jika Anda melewati ambang bebas, harga untuk penyimpanan tabel jauh lebih loyal daripada jumlah yang sama dari basis data SQL. Sebagai contoh, pada saat menulis artikel ini, saya telah membuat dua tabel, sejauh ini hanya dengan satu entri. Selama 18 hari dari periode pelaporan, saya menoleh padanya rata-rata 20-30 kali sehari dan 2 kopeck dihapuskan dari akun kredit untuk periode ini. Meningkatkan biaya tersebut untuk volume yang direncanakan, saya menyadari bahwa mereka lebih dari tercakup oleh potensi pendapatan dari aplikasi.
2. Sekarang Anda memiliki akun di Azure, kami melanjutkan untuk membuat akun penyimpanan.
Anda dapat melakukan ini semua dari halaman Koneksi Layanan Visual Studio yang sama, yang saya jelaskan di atas. Jika Anda tiba-tiba menutup halaman ini, Anda dapat membukanya dengan mengklik dua kali pada "Layanan Terhubung" di Solution Explorer. Setelah memilih layanan yang diperlukan, jendela dengan akun penyimpanan yang tersedia akan terbuka dan, untuk menambahkan yang baru, klik tombol yang sesuai.
Di jendela baru, Anda harus melakukan langkah-langkah berikut:- Untuk memulai, Anda harus masuk dengan akun Microsoft Anda. Anda perlu menggunakan akun yang terikat dengan langganan Anda atau akun Azure gratis.
- Setelah Anda masuk ke akun Anda, langganan Anda (a) akan muncul di bidang "Berlangganan". Semuanya sederhana dengan pilihan, sehingga komentar berlebihan.
- Di bidang "Nama", tentukan nama yang diinginkan dari layanan penyimpanan. Karena ini juga nama domain dari layanan, itu harus unik dalam semua akun yang tersedia di Azure, dan bukan hanya di dalam Anda sendiri.
- Bidang "Kategori harga" mengharuskan Anda untuk memahami perbedaan antara platform cloud dan hosting konvensional, karena dengan mengklik tautan di bawah bidang tersebut Anda dapat melihat daftar harga, tetapi bukan penjelasan yang masuk akal, yang memberi Anda setiap opsi. Tentu saja, di belantara tautan situs Anda dapat menemukan informasi komprehensif tentang semua singkatan ini seperti GRS dan LRS, tetapi ini berlebihan untuk pengembang rata-rata. Cukup untuk memahami bahwa semakin mahal tarifnya, semakin banyak pusat data akan terlibat dalam pemrosesan dan penyimpanan data Anda dan semakin tinggi kemungkinan keamanannya. Untuk proyek kecil, tingkat LRS terendah baik-baik saja.
- "Grup sumber daya" adalah kombinasi dari beberapa layanan Azure untuk manajemen tunggal. Dalam kasus kami, buat yang baru, tetapkan nama yang ramah dan lanjutkan.
- Hal terakhir yang harus dipilih adalah "Lokasi" untuk layanan Anda. Lokasi adalah lokasi sebenarnya dari pusat data yang akan bertanggung jawab untuk bekerja dengan data kami. Harap dicatat bahwa saya berbicara dalam bentuk jamak, karena di satu wilayah dapat ada beberapa pusat data dan pekerjaan dapat didistribusikan di antara mereka (jika Anda memilih kategori harga saran). Pilih salah satu yang paling dekat dengan basis pengguna utama Anda. Namun, jika Anda berencana untuk tumbuh ke skala seluruh dunia dan Anda membutuhkan respons maksimum di mana pun di dunia, tidak ada yang mengganggu Anda untuk setiap versi regional aplikasi untuk membuat akun penyimpanan terpisah dan menerapkan sinkronisasi data di antara mereka. Ini adalah tingkat ekstensibilitas yang tinggi yang merupakan keunggulan utama cloud.
3. Setelah membuat akun penyimpanan, itu akan ditambahkan ke daftar dan Anda dapat melanjutkan dengan mengklik tombol "Tambah". Hasil dari tindakan ini adalah menambahkan paket NuGet untuk bekerja dengan Azure ke proyek dan menyimpan string koneksi dalam file app.config proyek.
Sayangnya, tidak mungkin untuk bekerja dengan nilai-nilai dari file ini di UWP (atau mungkin dengan kruk yang mengerikan), jadi cukup salin string koneksi ke layanan penyimpanan dari sana ke tempat yang nyaman dalam proyek dan lanjutkan ke langkah berikutnya.
4. Sekarang tinggal membuat tabel dan mulai bekerja dengannya. Dan di sini dimulai pekerjaan individu, tergantung langsung pada tugas.
Faktanya adalah bahwa sebelum Anda mulai membuat tabel apa pun, Anda harus berpikir dengan hati-hati tentang arsitektur untuk menyimpan data Anda. Bekerja dengan penyimpanan tabel sangat nyaman sehingga membuat tabel baru langsung dari kode hanya masalah beberapa baris, dan dengan kenyamanan seperti itu ada keinginan alami untuk mengalokasikan tabel terpisah untuk setiap pengguna, karena pada akhirnya tugasnya adalah untuk menyinkronkan data antar perangkatnya. Namun, ketika bekerja dengan teknologi yang tidak dikenal, Anda tidak harus membuat keputusan tergesa-gesa dan Anda perlu mempertimbangkan pro dan kontra dengan hati-hati.
Artikel khusus
dalam manual ini dapat membantu dalam membuat keputusan yang tepat, tetapi bersiaplah untuk harus membacanya kembali beberapa kali, karena sangat sulit untuk mempelajari semua data segera, terutama dengan mempertimbangkan massa istilah baru.
Saya akan melanjutkan cerita dengan mempertimbangkan fakta bahwa Anda masih membaca manual dan memahami beberapa fitur bekerja dengan penyimpanan tabel. Sebagai contoh, saya menyadari bahwa secara konseptual sebuah tabel bukanlah semacam unit terisolasi dan lebih merupakan tempat untuk pengelompokan catatan secara logis. Ini mudah dimengerti jika Anda menyajikan tabel sebagai folder tempat Anda menyimpan file data. Folder dengan sendirinya tidak memakan ruang dan bukan merupakan bagian integral dari file, tetapi hanya mendefinisikan bagian dari path ke file yang logis, tetapi tidak perlu, untuk disimpan dalam folder ini.
Kesimpulan dari ini cukup sederhana - tidak ada yang mengganggu untuk menyimpan pengaturan semua pengguna dalam satu tabel, yang utama adalah bahwa pasangan nilai dalam kolom PartitionKey dan RowKey unik di dalam tabel. Ini lagi diimplementasikan dalam proyek saya, karena ID pengguna akan bertindak sebagai PartitionKey, dan misalnya, string "UserName" sebagai RowKey, yang akan memungkinkan kami untuk menentukan catatan unik di mana nama pengguna disimpan. Tapi seperti yang saya katakan di atas, kita perlu menimbang semua pro dan kontra, jadi mari kita menimbang:
- "Untuk" tabel terpisah untuk setiap data pengguna adalah kemudahan dalam memahami struktur data. Jika kita menganggap tabel sebagai folder berisi file, maka masuk akal bahwa semua file dari satu pengguna berada di folder yang sama dan lebih umum digunakan dengan arsitektur seperti itu.
- Semua faktor lainnya adalah "menentang" tabel terpisah. Data pengguna di dalam tabel terpisah - ini mudah akurat sampai jumlah tabel seperti itu di ribuan. Karena akun penyimpanan adalah tingkat yang lebih tinggi di atas tabel, tidak ada pengelompokan lain disediakan untuk mereka.
Mengingat basis pengguna potensial, kami berisiko tenggelam dalam ribuan tabel individual, kehilangan tabel yang memiliki nilai prioritas. Pada saat yang sama, menyimpan pengaturan semua pengguna dalam satu tabel menyederhanakan administrasi dan bekerja dengan data untuk mengumpulkan informasi statistik atau mengimplementasikan fungsi sosial.
Selain itu, biaya rendah menggunakan penyimpanan tabel memungkinkan Anda untuk menggandakan data dalam tabel terpisah, sesuai dengan logika yang diperlukan. Secara khusus, saya berencana untuk membuat tabel tambahan dengan nama pengguna, tautan ke avatar dan indikasi milik negara, yang akan digunakan untuk tabel penilaian atau fungsi sosial lainnya yang dapat ditambahkan ke aplikasi.
Jadi, ketika Anda menemukan struktur penyimpanan data, mari kita akhirnya menambahkan tabel baru. Karena kami menolak untuk membuatnya di level kode, ada dua opsi: melalui portal web Azure atau menggunakan alat khusus Microsoft Azure Storage Explorer, yang dapat diunduh dari storageexplorer.com. Dalam kedua kasus, perlu untuk memilih akun penyimpanan yang diinginkan dan di bagian "Tables / Tables Service" pilih "+ Table / Create Table". Dalam dialog yang muncul, masukkan nama yang diinginkan dan komit perubahan.
Setelah itu, Anda dapat bekerja dengan tabel baru dari kode tanpa masalah.
Operasi utama yang akan saya lakukan dengan tabel adalah penyisipan dan ekstraksi baris, yang disebut "entitas" dalam terminologi penyimpanan tabel. Istilah seperti itu lebih mudah dipahami ketika Anda menyadari bahwa untuk menyisipkan dan mengambil entitas, Anda perlu memetakannya kelas yang diwarisi dari TableEntity dari Microsoft.WindowsAzure.Storage.Table. Kelas penerus sudah akan berisi beberapa bidang yang diperlukan, seperti, misalnya, PartitionKey (nama bagian) dan RowKey (nama baris), dan bidang-bidang yang kami implementasikan secara mandiri akan menjadi kolom di baris (properti entitas).
Pertimbangkan contoh tabel di mana daftar semua pemain dengan nama, avatar, dan afiliasi negara mereka akan disimpan.
: Imports Microsoft.WindowsAzure.Storage Imports Microsoft.WindowsAzure.Storage.Table
Saya memutuskan untuk meletakkan metode untuk bekerja dengan tabel ke dalam kelas yang terpisah untuk kenyamanan bekerja dari berbagai titik aplikasi. Buat dan segera tambahkan konstanta yang dikenal sebelumnya:
Public Class AzureWorker Private Const AzureStorageConnectionString As String = " , app.config" Private Const GamerListTableNameString As String = "GamerList" ' âĻ End Class
Sekarang kita perlu membuat kelas yang akan kita petakan ke entitas (baris) di dalam tabel:
Private Class GamerListClodTableDataClass Inherits TableEntity Public Const RowKeyValue As String = "UserID" Public Sub New () RowKey = RowKeyValue End Sub Public Property UserName As String = "" Public Property UserountryID As String = "" Public Property UserAvatar As String = "" End Class
Kelas yang akan dipetakan harus diwarisi dari TableEntity dan memiliki bidang untuk data yang kami rencanakan untuk ditempatkan di tabel. Perhatikan bahwa pengaturan nilai untuk RowKey atau PartitionKey di tingkat kelas tidak diperlukan, tetapi dalam kasus saya, RowKey diatur karena tidak dapat diubah terlepas dari input lainnya.
Tapi, karena pada tahap ini Anda mungkin tidak sepenuhnya memahami esensi dari bekerja dengan penyimpanan tabel, saya akan menjelaskan logika yang ditetapkan pada tahap ini. Cara tercepat untuk bekerja dengan tabel adalah dengan menanyakan entitas dengan nama string dan nama bagian, jadi Anda harus mengetahui data ini terlebih dahulu. Selain itu, kombinasi PartitionKey dan RowKey harus unik di dalam tabel, yang berarti logis untuk menulis ID pengguna unik di salah satu kunci ini, dan memberikan kunci kedua nama apa pun yang akan selalu kita ketahui. Inilah yang dilakukan di kelas GamerListClodTableDataClass.
Tahap persiapan terakhir sebelum permintaan langsung ke tabel adalah pembuatan objeknya dalam fungsi terpisah:
Private Shared Function GetCloudTable(tableName As String) As CloudTable Dim storageAccount As CloudStorageAccount = CloudStorageAccount.Parse(AzureStorageConnectionString) Dim tableClient As CloudTableClient = storageAccount.CreateCloudTableClient() Dim table As CloudTable = tableClient.GetTableReference(tableName) Return table End Function
Ini dilakukan agar tidak menggandakan kode setiap kali kita ingin membaca atau menulis data ke tabel. Harap dicatat bahwa kode ini tidak membuat permintaan langsung ke cloud dan akan dieksekusi tanpa masalah ketika tidak ada koneksi. Yang dia lakukan adalah langkah demi langkah membuat objek tabel dari data yang ada, seperti string koneksi penyimpanan dan nama tabel.
Akhirnya, mari beralih ke bekerja secara langsung dengan tabel dan mulai dengan menyimpan data pengguna saat ini:
Public Shared Async Function SavedOrUpdateUserData(u As UserManager) As Task(Of Boolean) Dim table As CloudTable = GetCloudTable(GamerListTableNameString) Try If Await table.ExistsAsync Then Dim UserDataClodTableData As New GamerListClodTableDataClass With {.PartitionKey = u.UserId, .UserName = u.UserName.Trim, .UserountryID = u.UserountryID, .UserAvatar = "https://apis.live.net/v5.0/" & u.UserId & "/picture"} Dim insertOperation As TableOperation = TableOperation.InsertOrReplace(UserDataClodTableData) Await table.ExecuteAsync(insertOperation) Return True End If Catch ex As Exception End Try Return False End Function
Permintaan dibuat sebagai fungsi asinkron sehingga kode panggilan dapat memperoleh hasil dari eksekusi (True on success dan False on failure). Juga, parameter dari tipe UserManager diteruskan ke fungsi, yang merupakan referensi ke kelas dengan data pengguna. Kami membuat kelas seperti itu di artikel sebelumnya, dengan satu-satunya perbedaan adalah bahwa dalam versi ini ada bidang UserountryID yang menyimpan data tentang negara pengguna.
Untuk kueri ke tabel, pertama-tama Anda harus membuat objeknya menggunakan string koneksi ke repositori dan nama tabel (kami telah menempatkan proses ini ke dalam fungsi terpisah sebelumnya). Selanjutnya, Anda harus memeriksa keberadaan tabel dan, meskipun kami yakin bahwa kami memiliki tabel dengan nama itu, kesalahan dapat terjadi, misalnya, karena kurangnya konektivitas jaringan atau karena kegagalan di cloud (itulah sebabnya kode ini ditempatkan di Coba / Tangkapan). Kemudian, sebelum menulis ke tabel, Anda harus membuat turunan dari kelas UserDataClodTableData dan menetapkan nilai yang diperlukan untuk bidangnya dan hanya kemudian membuat operasi InsertOrReplace. Seperti yang dapat Anda tebak dari nama operasi, itu akan menyisipkan baris baru ke dalam tabel jika baris dengan pasangan yang sama dari PartitionKey dan RowKey tidak ada dalam tabel dan mengganti data jika baris tersebut sudah ada. Nah, tim ExecuteAsync terakhir, pada kenyataannya, akan melakukan tindakan yang direncanakan di sisi penyimpanan tabel.
Membaca data dari sebuah tabel semudah menulisnya. Misalnya, mari kita meminta nama pengguna:
Public Shared Async Function GetUserName(id As String) As Task(Of String) Dim table As CloudTable = GetCloudTable(GamerListTableNameString) Try If Await table.ExistsAsync Then Dim retrieveOperation As TableOperation = TableOperation.Retrieve(Of GamerListClodTableDataClass)(id, GamerListClodTableDataClass.RowKeyValue) Dim retrievedResult As TableResult = Await table.ExecuteAsync(retrieveOperation) If retrievedResult.Result IsNot Nothing Then Return CType(retrievedResult.Result, GamerListClodTableDataClass).UserName End If End If Catch ex As Exception End Try Return "" End Function
Kode ini hampir tidak berbeda dari yang sebelumnya dan juga dimulai dengan membuat objek tabel dan memeriksa keberadaannya. Lebih lanjut, seperti dalam rekaman, kami membuat operasi, tetapi kali ini operasi ekstraksi, yang memerlukan indikasi PartitionKey dan RowKey. Setelah itu, kami mengekstrak hasilnya menggunakan ExecuteAsync dan bekerja dengan objek yang dihasilkan dari tipe TableResult, yang sebenarnya turun untuk men-casting properti Result ke tipe kelas yang dipetakan dan mengekstraksi nama pengguna.
Bekerja dengan tabel tidak terbatas pada operasi membaca dan menulis dan mendukung banyak skrip yang berbeda. Misalnya, Anda bisa membuat kueri yang akan mengekstrak semua entitas dengan PartitionKey yang ditentukan atau semua entitas yang memiliki bidang yang ditentukan, tetapi penting untuk mengingat kecepatan operasi tersebut, serta jumlah data yang akan dikirim melalui jaringan.
Contoh di atas adalah yang paling optimal dari sudut pandang kecepatan permintaan, karena sistem pengalamatan kemungkinan besar akan menemukan entitas di sepanjang jalur "nama penyimpanan \ nama tabel \ PartisiKey + RowKey", namun, untuk mendapatkan hanya satu nama, kami memuat seluruh entitas secara keseluruhan, yang tidak menguntungkan pada jumlah data yang ditransfer.
Berikut ini adalah kode fungsi yang dimodifikasi dengan mempertimbangkan optimalisasi kueri maksimum:
Public Shared Async Function GetUserName(id As String) As Task(Of String) Dim table As CloudTable = GetCloudTable(GamerListTableNameString) Try If Await table.ExistsAsync Then Dim projectionQuery As TableQuery(Of DynamicTableEntity) = New TableQuery(Of DynamicTableEntity)().Where(TableQuery.CombineFilters(TableQuery.GenerateFilterCondition("PartitionKey", QueryComparisons.Equal, id), "and", TableQuery.GenerateFilterCondition("RowKey", QueryComparisons.Equal, GamerListClodTableDataClass.RowKeyValue))).Select({"UserName"}) Dim resolver As EntityResolver(Of String) = Function(pk, rk, ts, props, etag) Return props("UserName").StringValue End Function Dim result As TableQuerySegment(Of String) = Await table.ExecuteQuerySegmentedAsync(projectionQuery, resolver, Nothing) If result.Count > 0 Then Return result(0) End If End If Catch ex As Exception End Try Return "" End Function
Alih-alih membuat objek operasi, dalam kode ini kita membuat objek permintaan yang berisi beberapa metode untuk menentukan apa yang perlu diperoleh sebagai hasilnya. Metode Di mana membuat filter yang menunjukkan kebutuhan untuk mengembalikan hanya baris yang PartitionKey dan RowKey sama dengan nilai yang ditentukan, dan Pilih berikutnya menunjukkan bahwa hanya kolom UserName yang perlu dipilih.
Dengan permintaan seperti itu, tidak masuk akal untuk membandingkan hasilnya dengan kelas apa pun, oleh karena itu, IDictionary digunakan sebagai nilai balik, di mana kuncinya adalah nama kolom, dan nilainya adalah isinya. Karena fungsi ExecuteQuerySegmentedAsync tidak tahu hasil eksekusi yang akan diperoleh, dimungkinkan (dan dalam hal ini diperlukan) untuk melewati delegasi EntityResolver, yang merujuk ke fungsi yang mengambil nilai yang diinginkan dari kamus. Hasil dari semua ini menjadi TableQuerySegment di indeks pertama yang menyimpan nama pengguna yang diminta.
Secara umum, penggunaan kueri alih-alih operasi ekstraksi dasar memungkinkan Anda memperluas kemungkinan bekerja dengan tabel secara signifikan, namun berhati-hatilah, karena tidak seperti SQL klasik, di sini kecepatan pemrosesan kueri secara langsung bergantung pada parameternya. Tidak ada yang mengganggu Anda untuk mengeksekusi kueri untuk mengambil semua catatan pengguna yang namanya sama dengan yang diberikan, tetapi kueri seperti itu akan lebih panjang dari pada SQL. Untuk mempelajari ini, sekali lagi saya
mengarahkan Anda ke panduan desain tabel yang saya sebutkan di atas, dan saya juga menyarankan Anda mempelajari
artikel tersebut , yang memberikan contoh tentang cara bekerja dengan penyimpanan tabel.
Penting! Artikel tautan menggunakan kode untuk aplikasi .NET klasik dan berbeda dari implementasi UWP. Untungnya, perbedaan ini tidak signifikan dan analognya intuitif (paling sering perbedaannya ada pada awalan Async).Sebagai kesimpulan, saya akan membagikan hasil menggunakan penyimpanan Azure di proyek saya saat ini. Pada permulaan pertama, setelah menerima ID pengguna dan mengunduh data dari Live ID, saya sarankan dia memilih alias (nama panggilan) jika nama yang disimpan dalam profil tidak cocok untuknya. Kemudian julukan yang dimasukkan disimpan dalam kelas UserManager bukan yang standar, dan semua data ini disimpan dalam tabel GamerList. Di awal berikutnya, ID pengguna diterima di latar belakang dan alias diminta dari repositori. Akibatnya, pengguna melihat nama panggilannya di game, dan bukan nama dari profil standar.
Juga di masa depan, sebuah tabel dengan daftar pengguna akan berguna untuk memasukkan fungsi sosial ke dalam game dan, sekarang, saya telah membuat setidaknya satu aplikasi untuk data ini. Dalam pelaksanaan tugas ini, alat Azure seperti Penyimpanan Antrian dan Fungsi Azure akan membantu saya lagi, tapi saya akan membicarakan ini di salah satu artikel berikut.