Caching di lapisan bisnis vs. Caching di Lapisan Data

Saya selalu bekerja pada proyek-proyek di mana caching dilakukan pada DAL, pada dasarnya hanya ketika Anda akan membuat panggilan ke database, memeriksa apakah data sudah ada di dalam cache dan jika ya, itu hanya tidak membuat panggilan dan alih-alih mengembalikan data itu.

Saya baru saja membaca tentang caching pada lapisan bisnis, jadi pada dasarnya caching seluruh objek bisnis. Satu keuntungan yang dapat saya lihat langsung adalah waktu respons yang jauh lebih baik.

Kapan Anda lebih suka yang satu daripada yang lain? dan apakah caching di Business Layer merupakan praktik umum?

c# design design-patterns caching

— Emma
sumber

Apakah kinerja aplikasi Anda sangat penting sehingga caching di lapisan bisnis lebih baik daripada menghindari kejelasan panggilan tambahan ke repositori atau DAL-layer?

— JDT

Tidak, ini bukan dan setelah membaca balasan, saya pikir saya akan tetap pada caching di DAL. Tepuk tangan.

— Emma

Anda harus mempertimbangkan caching di atas Layer Bisnis Anda, dan juga berpikir tentang penskalaan.

— AK_

Jawaban:

Ini mungkin terlalu luas untuk jawaban yang pasti. Secara pribadi, saya merasa bahwa lapisan akses data adalah tempat yang lebih baik untuk caching, hanya karena itu seharusnya sangat sederhana - catatan masuk dan keluar dan hanya itu.

Lapisan bisnis mengimplementasikan banyak aturan tambahan dengan kompleksitas yang lebih tinggi, jadi lebih baik jika tidak juga harus mengelola masalah ketersediaan per-objek selain masalah konsistensi multi-objek di kelas yang sama (atau bahkan metode yang sama) - yang akan menjadi pelanggaran terang-terangan terhadap SRP.

(Tentu saja, saya hanya mencapai wawasan itu setelah kelas layanan saya tumbuh menjadi kompleksitas yang tidak dapat dikelola ketika mereka mencoba melakukan caching dan konfigurasi secara bersamaan. Tidak ada guru yang lebih baik daripada pengalaman, tetapi harganya pasti curam.)

— Kilian Foth
sumber

mengapa caching harus kompleks? mungkin dilakukan dengan AOP dan beberapa anotasi. Apakah masih melanggar SRP? mengapa tidak ketika dilakukan di DAL? juga IMHE Saya tidak pernah melihat kelas layanan "terlalu rumit" untuk di-cache; terlepas dari kerumitannya, sebuah layanan dapat dilihat sebagai kotak hitam dan hasilnya dapat di-cache

— user1075613

Akses data dan lapisan persistensi / penyimpanan adalah tempat alami untuk melakukan caching. Mereka melakukan I / O, menjadikannya berguna, tempat yang mudah untuk memasukkan caching. Saya berani mengatakan bahwa hampir setiap DAL atau lapisan kegigihan akan, saat matang, diberi fungsi caching - jika tidak dirancang seperti itu sejak awal.

Masalahnya adalah niat . Lapisan DAL dan ketekunan berhubungan dengan konstruksi tingkat rendah - misalnya, catatan, tabel, baris, dan blok. Mereka tidak melihat "bisnis" atau objek lapisan aplikasi, atau memiliki banyak wawasan tentang bagaimana mereka digunakan di tingkat yang lebih tinggi. Ketika mereka melihat beberapa baris atau selusin blok sedang dibaca atau ditulis, tidak jelas bahwa mereka mewakili. "Akun Jones yang saat ini kami analisis" tidak terlihat jauh berbeda dari "beberapa data referensi tingkat perpajakan dasar yang dibutuhkan aplikasi sekali saja, dan yang tidak akan direferensikan lagi." Pada lapisan ini, data adalah data adalah data.

Caching pada DAL / risiko lapisan persistensi memiliki data referensi pajak "dingin" di sana, dengan sia-sia menempati cache 12,2MB dan memindahkan beberapa informasi akun yang, pada kenyataannya, akan digunakan secara intensif hanya dalam satu menit. Bahkan manajer cache terbaik berhadapan dengan sedikit pengetahuan tentang struktur dan koneksi data tingkat yang lebih tinggi, dan sedikit wawasan tentang operasi apa yang akan segera hadir, sehingga mereka kembali ke algoritma dugaan waktu .

Sebaliknya, cache lapisan aplikasi atau bisnis hampir tidak begitu rapi. Ini memerlukan memasukkan operasi manajemen cache atau petunjuk di tengah logika bisnis lainnya, yang membuat kode bisnis lebih kompleks. Tetapi tradeoffnya adalah: Memiliki lebih banyak pengetahuan tentang bagaimana data tingkat makro terstruktur dan operasi apa yang muncul, ia memiliki peluang yang jauh lebih baik untuk memperkirakan efisiensi caching yang optimal ("clairvoyant" atau "Bélády Min").

Apakah memasukkan tanggung jawab manajemen cache ke dalam kode bisnis / aplikasi masuk akal adalah panggilan penilaian, dan akan bervariasi berdasarkan aplikasi. Dalam banyak kasus, walaupun diketahui bahwa lapisan DAL / kegigihan tidak akan benar-benar "benar," untungnya adalah mereka dapat melakukan pekerjaan yang cukup baik, bahwa mereka melakukannya dengan cara "bersih" secara arsitektur dan jauh lebih intensif untuk diuji. , dan penangkapan tingkat rendah menghindari peningkatan kompleksitas kode bisnis / aplikasi.

Kompleksitas yang lebih rendah mendorong kebenaran dan keandalan yang lebih tinggi, dan waktu ke pasar yang lebih cepat. Itu sering dianggap sebagai tradeoff yang hebat - caching yang kurang sempurna, tetapi kualitas yang lebih baik, kode bisnis yang lebih tepat waktu.

— Jonathan Eunice
sumber

Terima kasih balasannya. Setelah membaca balasan Anda dan orang lain, saya pikir saya pasti tidak perlu melakukan cache di lapisan bisnis. Itu hanya akan menambah kompleksitas keseluruhan produk.

— Emma

Salah satu masalah dengan model "lapisan" adalah bahwa mekanisme caching yang efisien sering perlu menggunakan informasi yang tidak tersedia pada satu lapisan. Apa yang akan Anda pikirkan, karena memiliki lapisan bisnis yang lulus "petunjuk" ke lapisan data tentang "rencana" keseluruhannya? Lapisan data awalnya bisa mengabaikan sebagian besar petunjuk seperti itu, tetapi jika kemacetan ditemukan, beberapa logika dapat ditambahkan yang, ketika diberi petunjuk tertentu, akan mengubah strategi caching dengan cara khusus bisnis.

— supercat

Poin luar biasa, @supercat. Saya akan menyebutkan strategi petunjuk / pragma, tetapi jawabannya sudah lama. Tapi kamu benar sekali. Petunjuk lapisan bisnis untuk lapisan bawah tentang cara memprioritaskan cache, atau "apa yang harus dijepit," adalah cara yang cukup umum / berguna untuk mendapatkan cache tingkat yang lebih tinggi tanpa membuat kode bisnis melakukan semuanya, atau menjadi terlalu terjebak dalam mengelola penyimpanannya sendiri hirarki.

— Jonathan Eunice

@ JonathanEunice: Yang menyenangkan tentang petunjuk adalah bahwa kode tidak perlu melakukan banyak hal dengan mereka pada awalnya. Banyak sistem memiliki beberapa hambatan jelas yang mendominasi kinerjanya, tetapi mungkin sulit memprediksi apakah yang mana akan cukup buruk. Menambahkan sedikit logika cache yang jelek di beberapa titik kritis mungkin lebih baik daripada menabrak banyak logika cache di tempat-tempat yang benar-benar tidak penting.

— supercat

Persis. Terutama jika Anda memiliki cache level rendah "cukup bagus" yang sudah ada di lapisan persistensi / akses. Anda mungkin hanya perlu sedikit informasi prioritas tambahan untuk beralih dari "cukup bagus" menjadi "sangat bagus."

— Jonathan Eunice

Caching pada DAL sangat mudah dan sederhana

DAL Anda adalah lapisan akses data pusat, yang berarti bahwa setiap dan semua akses data dapat dikontrol melalui kelas-kelas di sana. Karena membaca dan bertahan terjadi pada lapisan-lapisan itu, sama mudahnya untuk menghapus atau memperbarui entri cache ketika perubahan terjadi.

Caching dalam bisnis ini fleksibel

Caching pada bisnis memberi para pengembang fleksibilitas untuk menentukan apakah penggunaan konkret suatu objek akan mendapat manfaat dari caching. Tergantung pada struktur layanan back-end aplikasi atau proses otomatis mungkin mengubah data yang di-cache di bagian lain. Dengan caching dalam bisnis, pengembang dapat menentukan apakah objek bisnis tertentu akan memiliki kemungkinan data basi dan mendapatkan kinerja, atau memiliki status objek bisnis yang paling terkini dengan mengorbankan kinerja.

— JDT
sumber