Ekstensi Reaktif .Net memberi pengembang serangkaian fitur untuk mengimplementasikan model pemrograman reaktif bagi pengembang .Net untuk membuat penanganan peristiwa lebih sederhana dan lebih ekspresif menggunakan tindakan deklaratif. Meskipun landasan utama penskalaan reaktif adalah antarmuka IObserver dan IObservable, sebagai pengembang, Anda sering tidak perlu mengimplementasikan antarmuka ini sendiri. Perpustakaan mendukung tipe bawaan Subject<T>, yang mengimplementasikan antarmuka dan mendukung banyak fungsi.
Tema adalah dasar untuk berbagai topik yang tersedia di perpustakaan, dan ada tema lain - ReplaySubject<T>, BehaviorSubject,<T> dan AsyncSubject<T>. Sangat berguna untuk memahami perbedaan penting di antara mereka dan cara menggunakannya untuk memanfaatkan perpustakaan dengan lebih baik.
Pada artikel ini, kita akan membandingkan Subjek<T> dan saudaranya, mencoba mengilustrasikan perbedaan antara perilaku mereka.
Subyek<T>
Seperti disebutkan sebelumnya, Subjek<T> adalah dasar untuk tema yang tersedia, menyediakan cara mudah untuk menggunakan perpustakaan tanpa harus mengimplementasikan antarmuka IObservable<T> dan IObserver<T> sendiri. Demonstrasi sederhana dari jenis tema ditunjukkan di bawah ini.
Dalam kode di atas, kami membuat <T>instance Subject, dan karena mengimplementasikan<T> IObserver dan IObserverable<T>, gunakan instance yang sama untuk berlangganan dan menerbitkan nilai ke IObserver. Poin penting lainnya yang perlu diperhatikan di sini adalah bagaimana kita menggunakan kelebihan beban metode Subscribe untuk menerima tindakan sebagai input. Ini akan dilakukan untuk setiap nilai yang diterbitkan, dalam hal ini mencetak nomor ke konsol.
Mari kita coba tampilkan nilai yang diterbitkan dan nilai yang dicetak IObserver (dalam Tindakan ini<T>) ke konsol pada gambar berikut. Ini akan membantu kami dengan mudah membandingkan saudara kandung dan varian yang tersisa.
Baris pertama mewakili nilai yang diterbitkan, dan baris kedua mewakili nilai yang diterima oleh IObserver. Selain itu, kami telah menambahkan garis untuk menunjukkan pada titik mana pengamat berlangganan aliran selama eksekusi. Garis ini diwakili oleh garis putus-putus vertikal.
Dalam kode di atas, kami melihat bahwa pengamat berlangganan aliran data sebelum menerbitkan nilai pertama. Gambar menunjukkan baris Subscriber yang ditempatkan sebelum elemen pertama. Seperti yang Anda lihat dari baris keluaran, ini tidak berpengaruh pada output (pada titik ini).
Tetapi bagaimana jika pengamat hanya berlangganan data setelah beberapa nilai telah dipublikasikan? Apakah ini berdampak pada data yang diterima oleh pengamat? Sebelum melihat outputnya, mari kita tulis kode yang sama terlebih dahulu.
Dalam kode di atas, kita dapat mengamati bahwa pengamat berlangganan aliran data hanya setelah dua nilai (1 dan 2) dipublikasikan. Seperti yang diharapkan, ini akan menyebabkan pengamat tidak menerima data yang dipublikasikan sebelum memanggil metode berlangganan. Seperti yang ditunjukkan pada gambar di bawah ini.
Bagaimana jika Anda ingin membaca semua nilai yang dipublikasikan, bahkan jika pengamat terlambat berlangganan? Di sinilah ReplaySubject<T> berperan.
Subjek Pemutaran <T>Ulang
ReplaySubject<T> menyimpan nilai dalam cache dan memutarnya ulang untuk pelanggan nanti. Ini berguna untuk menghindari kondisi balapan. Mari kita ubah kode sebelumnya untuk menggunakan ReplaySubject<T> dan lihat bagaimana pengaruhnya terhadap apa yang diterima pengamat.
Seperti yang ditunjukkan pada kode di atas,<T> <T>hampir tidak ada perubahan dalam kode kecuali kita sekarang menggunakan ReplaySubject alih-alih subjek. Diagram berikut menggambarkan dampak pada data yang diterima oleh pengamat.
Seperti yang ditunjukkan pada gambar, nilai yang di-cache sekarang diputar ulang ke pelanggan meskipun pelanggan berlangganan nanti. Tentu saja, fitur berguna ini ada harganya. Implementasi ini akan menyimpan cache setiap nilai yang diterbitkan oleh pelanggan, yang dapat menyebabkan masalah memori yang buruk ketika jumlah data secara signifikan lebih besar.
Namun, ReplaySubject<T> memiliki lebih dari satu cara untuk mengatasi masalah ini. Demi contoh ini, kita akan melihat dua contoh yang akan menggunakan batasan ukuran dan waktu untuk membatasi nilai yang di-cache.
Sebagai kasus pertama, kita akan menggunakan ukuran cache untuk membatasi nilai cache. <T>Konstruktor ReplaySubject menyediakan kelebihan beban, yang menerima bilangan bulat yang mewakili ukuran buffer cache (jumlah elemen maksimum). Dalam contoh kita, mari kita ubah kode untuk membatasi ukuran cache menjadi 1.
Perhatikan bagaimana kita menggunakan <T>kelebihan beban konstruktor ReplaySubject untuk menyediakan ukuran Cache sebagai 1. Ini membatasi penembolokan dan memastikan bahwa hanya satu elemen yang di-cache dan diganti dengan elemen baru segera setelah diterbitkan. Dampak dari perubahan tersebut ditunjukkan di bawah ini.
Cara lain untuk membatasi caching adalah dengan membatasi waktu item yang di-cache, atau dengan kata lain, untuk memberikan waktu kedaluwarsa untuk item yang di-cache.
Mari kita tulis kode untuk mengilustrasikan contoh itu.
Mirip dengan kode sebelumnya, kita menggunakan<T> kelebihan beban konstruktor ReplaySubject untuk menentukan waktu kedaluwarsa item dalam cache. Untuk menunjukkan kasus kami, kami memperkenalkan penundaan antara rilis nilai.
Karena dibutuhkan 1200 ms penuh sebelum pengamat berlangganan, setiap elemen yang melebihi waktu kedaluwarsa 1000 ms akan dihapus dari cache. Dalam contoh ini, ini akan menyebabkan nilai 1 dihapus dari cache dan tidak akan diputar ulang ke pelanggan yang terlambat. Seperti yang ditunjukkan pada gambar di bawah ini.
Ada <T>kelebihan beban lain untuk ReplaySubject yang memberikan lebih banyak fleksibilitas dan menyempurnakan nilai yang di-cache, tetapi misalnya, kami akan menyimpan dua contoh yang sudah dibahas di atas.
Perilaku Subjek<T>
BehaviourSubject <T>sangat mirip dengan ReplaySubject<T> karena membantu menyimpan nilai cache. Tetapi ada perbedaan yang signifikan. BehaviourSubject<T> hanya menyimpan nilai yang terakhir diterbitkan. Sebelum kita membahas lebih lanjut, mari kita tulis beberapa kode.
Jika BehaviorSubject<T> hanya menyimpan satu nilai dalam cache (yang terakhir diketahui), apa bedanya dengan ReplaySubject ukuran 1<T>? Diagram berikut dengan jelas mencerminkan situasi kode di atas.
Namun, ini tidak sepenuhnya benar. Ada dua perbedaan penting yang perlu dipahami di sini. Yang pertama adalah adanya default. Perhatikan bahwa dalam kode di atas, kami <T>memberikan nilai 0 sebagai default di konstruktor BehaviourSubject. Jika tidak ada nilai dalam cache (atau dengan kata lain, tidak ada data yang dipublikasikan sebelum pengamat berlangganan), nilai default akan ditampilkan. Ini berbeda dengan ReplaySubject, yang memiliki ukuran 1<T>, yang tidak memiliki nilai apa pun. Kode berikut dan representasi visual urutan menunjukkan perilaku ini.
Perbedaan kedua adalah bagaimana BehaviorSubject<T> dan ReplaySubject<T> berperilaku saat berlangganan urutan yang telah selesai. Saat Anda berlangganan setelah selesai, BehaviorSubject <T> tidak akan memiliki nilai, seperti yang ditunjukkan pada kode di bawah ini.
Pelanggan dijamin tidak akan menerima nilai apa pun karena langganan terjadi setelah selesai.
Namun, <T>ini adalah kasus dengan ReplaySubject . Tidak ada jaminan bahwa pengamat tidak akan menerima nilai apa pun, seperti yang ditunjukkan pada kode di bawah ini.
Seperti yang ditunjukkan pada kode di atas, cache berukuran 1 dan bahkan jika langganan dipanggil setelah panggilan selesai, cache akan tetap ada (sampai kondisi kedaluwarsa terpenuhi), jadi dalam hal ini nilai terakhir yang diterbitkan akan diterima.
AsinkronSubjek<T>
AsyncSubject <T>adalah saudara terakhir dari Subject yang akan kita jelajahi dalam artikel ini<T>, dan sangat mirip dengan dua sebelumnya (ReplaySubject dan BehaviourSubject) karena juga menyimpan hasil dalam cache. Tapi sekali lagi ada perbedaan yang signifikan. AsyncSubject menerbitkan nilai cache terakhir hanya jika urutan ditandai sebagai selesai <T> (hanya menyimpan satu nilai, nilai terakhir).
Pertimbangkan kode berikut.
Ini akan menghasilkan nilai bagi pengamat bahwa urutan ditandai sebagai nilai terakhir yang diterbitkan sebelum selesai - nilai 4. Seperti yang ditunjukkan pada gambar di bawah ini.
Tetapi apa yang terjadi jika kita melewatkan panggilan yang menandai urutan sebagai selesai? Mari kita komentari baris dan coba lagi.
Ini tidak menghasilkan data apa pun untuk pengamat karena AsyncSubject<T> menerbitkan hasil hanya setelah urutan ditandai sebagai selesai.
Ini adalah perbedaan signifikan yang harus diingat oleh siapa pun yang menggunakan AsyncSubject<T>.
kesimpulan
Artikel ini menunjukkan <T>perbedaan antara berbagai saudara kandung Subjek dan beberapa variasinya. Seringkali berguna untuk menyadari perbedaan halus ini, karena mereka mungkin menunjukkan perilaku yang berbeda dari yang Anda harapkan jika Anda tidak menyadarinya.
Tautan asli:Login hyperlink terlihat.
|
Diposting pada 27/01/2024 12.17.19
|
|
|
|
Tuan tanah|
Diposting pada 27/01/2024 12.19.47
|
