Klarifikasi MVVM

Kami akan menulis aplikasi WPF pertama kami dan menjadi terbiasa dengan pola MVVM. Kami telah membangun banyak aplikasi Winform dan memiliki arsitektur yang sangat sukses bagi kami. Kami mengalami sedikit kesulitan menerjemahkan arsitektur itu atau menentukan di mana potongan-potongan tertentu arsitektur kami cocok dengan model MVVM.

Secara historis kami memiliki Gui (exe utama) yang kemudian berkomunikasi dengan BusinessLogic dll. BusinessLogic berkomunikasi dengan DAL dll melalui layanan web dan DAL berinteraksi dengan DB. DAL, BusinessLogic, dan GUI semuanya merujuk pada BusinessObjects dll.

Arsitektur Asis

Beberapa transisi ke MVVM cukup mudah. Gui kami akan tetap berisi tampilan, BusinessOjbects kami akan tetap berisi model dan DAL kami masih akan berinteraksi dengan DB (meskipun teknologi untuk mengimplementasikannya dapat berubah).

Apa yang kami tidak yakin adalah komponen BusinessLogic kami. Secara historis ini akan menyediakan fungsi bagi GUI untuk memanggil kemudian mengisi kontrol dalam tampilan (mis. GetCustomerList yang akan mengembalikan daftar objek Pelanggan atau fungsi CRUD khas).

Penutup utama yang kita miliki adalah apakah pola MVVM akan meminta komponen tambahan untuk menampung ViewModels atau jika kita hanya mengubah pemikiran kita dan memigrasikan apa yang telah kita gunakan sebagai komponen BusinessLogic kita ke ViewModels?

Apakah komponen BusinessLogic kami mewakili ViewModels?

architecture mvvm

— pengguna7676
sumber

Ini terdengar agak seperti solusi mencari masalah. Apakah ada alasan kuat mengapa Anda pindah ke MVVM? Saya penggemar pola tetapi apakah solusi Anda sebelumnya tidak berfungsi? Model tampilan seperti presenter pengawas. Ini berisi logika presentasi dan memunculkan data melalui pengikatan data. Seharusnya tahu tentang logika bisnis Anda dan dapat menjangkau tingkat itu, tapi saya tidak akan menciutkan logika bisnis ke dalam model tampilan itu sendiri.

— Jeremy Likness

Jawaban:

Secara umum, saya tidak akan menempatkan logika bisnis di lapisan model tampilan. Tetapi istilah "Logika Bisnis" menyesatkan.

Eric Evans menggunakan model di mana logika bisnis dibagi menjadi dua kategori

Logika domain - Logika yang terkait dengan domain masalah aktual yang Anda selesaikan
Logika aplikasi - Logika terkait dengan fakta, bahwa Anda sedang membangun aplikasi

Dia menyebutkan contoh aplikasi akuntansi. Aturan tentang akun, pos, akun pajak, dll. Adalah aturan domain, aturan yang berkaitan dengan domain akuntansi. Logika tentang impor / ekspor CSV tidak ada hubungannya dengan domain akuntansi. Aturan ini ada murni karena kami sedang membangun aplikasi perangkat lunak. Ini adalah contoh-contoh logika aplikasi.

Aturan domain harus TIDAK PERNAH masuk ke lapisan model tampilan. Jika Anda mengikuti pola MVVM, maka aturan domain berjalan, tanpa pertanyaan, di lapisan model.

Aturan aplikasi, seperti impor / ekspor CSV, bisa masuk dalam lapisan model tampilan. Tetapi secara pribadi, saya lebih suka memisahkannya menjadi lapisan logika aplikasi terpisah.

Model Tampilan harus sangat sederhana. Mencari data yang diperlukan oleh tampilan dalam model yang sesuai, memperbarui model ketika tampilan berubah, mendengarkan peristiwa dalam model, dan menyebarkan acara tersebut ke tampilan, memungkinkan tampilan diperbarui ketika model diperbarui di belakang layar (jika ada).

Secara pribadi saya akan memastikan bahwa lapisan model tampilan hanya berisi satu jenis logika, logika presentasi.

— Pete
sumber

Jawaban yang sangat bagus. Saya suka titik memastikan ViewModel hanya berisi logika Presentasi. Bisakah Anda menambahkan tautan yang terkait dengan poin Eric Evans Anda?

— user7676

Saya ragu saya dapat menemukan tautan, karena saya percaya saya mendapatkannya dari bukunya, Domain-Driven Design. Bagaimanapun, saya pikir ini adalah contoh yang sangat baik dari perbedaan antara domain dan logika aplikasi. Lebih lanjut tentang buku di sini books.google.dk/books/about/…

— Pete

Iya.

Lapisan logika bisnis diwakili oleh lapisan VM. Jadi migrasi saja model mental Anda.

Untuk membantu dengan migrasi model mental Anda, satu sedikit nuansa adalah bahwa objek GUI (Tampilan) harus terikat ke objek dalam lapisan VM. Ikatan itu diterjemahkan menjadi | menyiratkan bahwa Lihat tidak lagi menjadi lapisan yang "membuat panggilan" untuk mengambil sesuatu yang lain. Panggilan untuk pengambilan data akan datang dari VM sebagai gantinya.

Untuk lebih menjelaskan: Ya, objek dalam Tampilan perlu diubah untuk memicu urutan hal-hal yang akan membuat panggilan. Tapi View tidak melakukan panggilan itu sendiri. Dan dalam hal ini, saya menganggap klik tombol setara dengan sesuatu dalam Tampilan yang berubah, tetapi masih belum melakukan panggilan.

Dalam kasus pertama, objek View itu akan terikat ke objek VM. VM harus mendengarkan acara yang diubah properti pada objek terikat. Acara perubahan objek kemudian dapat ditransfer ke fungsi VM untuk membuat panggilan Model.

Dalam kasus kedua (acara klik tombol), acara perubahan (klik) dapat ditransfer ke panggilan fungsi yang diekspos oleh VM.

Either way, itu selalu merupakan peristiwa yang berurutan ke dalam VM yang kemudian memanggil Model yang pada gilirannya memanggil DAL / DB.

Saya memunculkannya karena beberapa kode WinForm digunakan untuk membuat panggilan ke lapisan DB langsung dari kode di belakang WinForm GUI. Pendekatan itu memecah pemisahan yang disediakan MVVM.

Terima kasih atas konfirmasinya. Kami memahami nuansa bagaimana View berinteraksi dengan ViewModel dan akan tetap menggunakan model yang mengikat dan menjatuhkan "calling".

— user7676

Saya perhatikan bahwa jawaban ini kehilangan suara. Saya ingin tahu apakah downvoter akan mengomentari mengapa? Atau mungkin menambahkan jawaban mereka sendiri jika mereka tidak membagikan sudut pandang ini.

— user7676

Saya setuju bahwa lapisan logika bisnis diwakili oleh lapisan VM, namun saya pikir bagian dari jawaban Anda mungkin membingungkan. The ViewLapisan ini dimaksudkan untuk menjadi representasi visual dari ViewModel atau Model, jadi daripada mengatakan acara klik ditransfer ke panggilan fungsi pada VM, definisi yang lebih baik akan mengatakan Command di VM akan diberikan sebagai tombol di layer View. Juga, saya biasanya tidak suka lapisan Model saya dapat mengakses DAL secara langsung, jadi aliran aplikasi saya biasanya pergi VM -> DAL -> DB, di mana VMdan DALkeduanya menggunakan Modelobjek data biasa .

— Rachel

Saya tidak setuju dengan jawaban ini. ViewModel adalah model tampilan, ini berisi logika tampilan, bukan logika bisnis. ViewModels adalah bagian dari lapisan presentasi

— simoraman

@simoraman - Pola MVPVM sesuai dengan apa yang Anda sarankan. Saya pikir MVPVM adalah pola yang baik, tetapi agak berat untuk aplikasi yang lebih kecil. Saya benar-benar akan mendorong Anda untuk memberikan jawaban dan berkontribusi pada pertanyaan ini.

Anda benar bahwa pada dasarnya Anda akan mengganti BusinessLogic dll dengan layer ViewModel Anda, namun saya pikir perbedaan terbesar yang akan Anda hadapi adalah bagaimana layer View / UI berinteraksi dengan layer ViewModel / BusinessLogic Anda.

Di WinForms, GUI adalah aplikasi Anda, dan bertanggung jawab atas aliran aplikasi. Di WPF / MVVM, ViewModels Anda adalah aplikasi Anda, dan GUI menjadi antarmuka yang mudah digunakan untuk berinteraksi dengan ViewModels.

Misalnya, dengan WinForms, Anda mungkin memiliki DataGrid dan Tombol, dan ketika Anda mengklik Tombol itu Anda memanggil BusinessLogicLayer.GetProducts()dan memuat objek Produk yang dihasilkan ke dalam DataGrid.

Dengan WPF, Anda akan memiliki ViewModel yang berisi ObservableCollection<Products>dan dan ICommand GetProducts, dan menjalankan perintah memanggil DAL dan memuat koleksi produk. Tetapi untuk menyediakan antarmuka yang ramah pengguna untuk ini, Anda akan membuat Tampilan yang membuat ViewModel Anda menggunakan DataGrid untuk koleksi Produk, dan Tombol untuk perintah GetProducts.

Saya sebenarnya menulis posting yang cukup baru untuk blog saya tentang perubahan pola pikir ketika pindah dari WinForms ke WPF di blog saya , dan saya pikir cara terbaik untuk meringkas perbedaannya adalah dengan gambar-gambar ini:

— Rachel
sumber

Saya setuju dengan GlenH7, ini adalah jawaban yang bagus untuk seseorang yang memulai dengan WPF. Kami mendapatkan perubahan paradigma interaksi antara View dan Model View jadi ini tidak benar-benar pada topik untuk pertanyaan yang saya ajukan.

— user7676