Logika bisnis dalam MVC [ditutup]

184

Saya punya 2 pertanyaan:

Q1. Di mana tepatnya "logika bisnis" terletak pada pola MVC? Saya bingung antara Model dan Pengendali.

Q2. Apakah "logika bisnis" sama dengan "aturan bisnis"? Jika tidak, apa bedanya?

Akan lebih bagus jika Anda bisa menjelaskan dengan contoh kecil.

— hmthur
sumber

173

Aturan bisnis masuk dalam model.

Katakanlah Anda sedang menampilkan email untuk milis. Pengguna mengklik tombol "hapus" di sebelah salah satu email, pengontrol memberi tahu model untuk menghapus entri N, lalu memberi tahu tampilan model yang telah diubah.

Mungkin email admin tidak boleh dihapus dari daftar. Itu aturan bisnis, bahwa pengetahuan termasuk dalam model. Pandangan akhirnya dapat mewakili aturan ini entah bagaimana - mungkin model memperlihatkan properti "IsDeletable" yang merupakan fungsi dari aturan bisnis, sehingga tombol hapus pada tampilan dinonaktifkan untuk entri tertentu - tetapi aturan itu sendiri tidak terkandung dalam tampilan.

Model ini akhirnya menjadi penjaga pintu untuk data Anda. Anda harus dapat menguji logika bisnis Anda tanpa menyentuh UI sama sekali.

— Lumpur
sumber

5

Terima kasih untuk contohnya. Untuk entri email admin (mengontrol apakah bisa dihapus atau tidak), bisakah kita tidak mengontrolnya dengan menggunakan pengontrol kami?

— hmthur

2

@mud bagaimana jika kita membagi model kita menjadi dua lapisan lagi yaitu lapisan layanan dan repositori ... lapisan layanan bertanggung jawab atas logika bisnis dan repositori bertanggung jawab atas lapisan data ...?

— Naga

3

@PeterMatisko "Model hanya boleh membawa data." Anda tidak memahami apa yang dimaksud M dalam "MVC". V murni presentasi. C adalah perekat antara presentasi dan model. (Faktanya, "VC" sering dianggap sebagai lapisan presentasi, dan variasi populer dari MVC seperti MVVM - Model View Viewmodel - membuatnya lebih jelas.) M adalah segalanya : semua data dan logika aplikasi Anda. Anda dapat memisahkan data dan logika bisnis di dalam lapisan ini, dan Anda dapat menyebut bagian data dari lapisan ini sebagai "model" Anda, tetapi bukan itu yang dimaksud dengan "M" dalam "MVC".

— Lumpur

1

@PeterMatisko "dalam laravel, orang-orang kemudian membuang semuanya ke dalam pengontrol atau model. Arsitektur yang buruk." Buruk bagaimana ? Lebih spesifik. "V" berarti "tampilan". Segala sesuatu yang bukan pandangan harus masuk dalam "M" atau "C". "MVC tidak cukup, itu tidak berbicara secara eksplisit tentang logika bisnis dan di mana harus meletakkannya" Tentu saja. "M" adalah model aplikasi Anda, yang merupakan data Anda, logika bisnis di sekitarnya, dan apa pun dan segala sesuatu yang bukan presentasi. "V" dan "C" adalah lapisan presentasi, input dan output pengguna.

— Lumpur

2

@Mud Masalahnya adalah, bahwa laravel memanggil 'Model' hanya pembawa data. Ketika tutorial mengatakan bahwa Laravel menggunakan MVC dan kemudian Anda melihat bahwa 'Model' memiliki tujuan yang sangat spesifik, maka Anda berakhir tanpa petunjuk di mana harus meletakkan logika bisnis. Dan satu-satunya tempat yang masuk akal adalah controller, yang tidak bagus. Saya tidak mengada-ada, saya hanya berkomentar tentang proyek laravel khas (dan tutorial) yang sering saya lihat.

— Peter Matisko

191

Fist semua:
Saya percaya bahwa Anda mencampur pola MVC dan prinsip-prinsip desain berbasis n-tier.

Menggunakan pendekatan MVC tidak berarti Anda tidak boleh melapisi aplikasi Anda.
Mungkin membantu jika Anda melihat MVC lebih seperti ekstensi dari lapisan presentasi.

Jika Anda memasukkan kode non-presentasi di dalam pola MVC Anda mungkin segera berakhir dengan desain yang rumit.
Karena itu saya menyarankan agar Anda meletakkan logika bisnis Anda ke dalam lapisan bisnis yang terpisah.

Lihat saja ini: artikel Wikipedia tentang arsitektur multitier

:

Hari ini, MVC dan model-view-presenter (MVP) serupa adalah pola desain Pemisahan Kekhawatiran yang berlaku secara eksklusif untuk lapisan presentasi sistem yang lebih besar.

Lagi pula ... ketika berbicara tentang aplikasi web perusahaan , panggilan dari UI ke lapisan logika bisnis harus ditempatkan di dalam pengontrol (presentasi).

Itu karena pengontrol benar-benar menangani panggilan ke sumber daya tertentu, meminta data dengan membuat panggilan ke logika bisnis dan menautkan data (model) ke tampilan yang sesuai.

Mud memberi tahu Anda bahwa aturan bisnis masuk ke dalam model.
Itu juga benar, tetapi ia mencampuradukkan model (presentasi) ('M' dalam MVC) dan model lapisan data dari desain aplikasi berbasis tier.
Jadi, valid untuk menempatkan basis data Anda terkait aturan bisnis dalam model (lapisan data) aplikasi Anda.
Tetapi Anda tidak harus menempatkan mereka dalam model lapisan presentasi terstruktur MVC Anda karena ini hanya berlaku untuk UI tertentu.

Teknik ini tidak tergantung apakah Anda menggunakan desain yang digerakkan domain atau pendekatan berbasis skrip transaksi.

Biarkan saya memvisualisasikannya untuk Anda:

Lapisan presentasi: Model - View - Controller

Lapisan bisnis: Logika domain - Logika aplikasi

Lapisan data: Repositori data - Lapisan akses data

Model yang Anda lihat di atas berarti bahwa Anda memiliki aplikasi yang menggunakan MVC, DDD, dan lapisan data yang tidak bergantung pada basis data.
Ini adalah pendekatan umum untuk merancang aplikasi web perusahaan yang lebih besar.

Tetapi Anda juga dapat mengecilkannya untuk menggunakan lapisan bisnis non-DDD sederhana (lapisan bisnis tanpa logika domain) dan lapisan data sederhana yang menulis langsung ke database tertentu.
Anda bahkan dapat menjatuhkan seluruh lapisan data dan mengakses database langsung dari lapisan bisnis, meskipun saya tidak merekomendasikannya.

Triknya ... Saya harap ini membantu ...

[Catatan:] Anda juga harus menyadari fakta bahwa saat ini ada lebih dari satu "model" dalam suatu aplikasi. Umumnya, setiap lapisan aplikasi memiliki modelnya sendiri. Model lapisan presentasi adalah tampilan spesifik tetapi sering independen dari kontrol yang digunakan. Lapisan bisnis juga dapat memiliki model, yang disebut "domain-model". Ini biasanya terjadi ketika Anda memutuskan untuk mengambil pendekatan berbasis domain. "Model domain" ini berisi data dan juga logika bisnis (logika utama program Anda) dan biasanya tidak tergantung pada lapisan presentasi. Lapisan presentasi biasanya memanggil lapisan bisnis pada "peristiwa" tertentu (tombol ditekan dll.) Untuk membaca data dari atau menulis data ke lapisan data. Lapisan data mungkin juga memiliki modelnya sendiri, yang biasanya terkait dengan basis data.

Pertanyaannya adalah: bagaimana hal ini sesuai dengan konsep MVC?

Jawab -> Tidak!
Ya - memang agak, tapi tidak sepenuhnya.
Ini karena MVC adalah pendekatan yang dikembangkan pada akhir 1970-an untuk bahasa pemrograman Smalltalk-80. Pada saat itu GUI dan komputer pribadi sangat tidak umum dan web di seluruh dunia bahkan tidak ditemukan! Sebagian besar bahasa pemrograman dan IDE saat ini dikembangkan pada 1990-an. Pada waktu itu komputer dan antarmuka pengguna sama sekali berbeda dari yang ada di tahun 1970-an.
Anda harus mengingatnya saat berbicara tentang MVC.
Martin Fowler telah menulis artikel yang sangat bagus tentang MVC, MVP dan GUI hari ini.

— jujur
sumber

10

+1 untuk cantuman dengan benar perbedaan antara aplikasi mvc dan n-tier. Sebagian besar aplikasi perusahaan yang saya kembangkan memiliki n-tier dan menggunakan mvc sebagai lapisan presentasi saja.

— Retired_User

Katakanlah 1) Lihat Model di MVC (Lapisan Presentasi) 2) Beberapa Teknologi C # (Lapisan Bisnis) untuk Transaksi Resmi, Logika Aturan Bisnis Inti. 3) Repositori dan Unit kerja dalam (Lapisan Akses Data) Harap pandu beberapa teknologi (atau Pola Praktik Terbaik) yang dapat digunakan untuk membangun Lapisan Bisnis yang seharusnya bebas untuk mengizinkan dan mengekspos model, repositori untuk mengakses dari pengontrol di lapisan presentasi (Atas Lapisan). Pada dasarnya saya percaya Tambah, Hapus, Perbarui & Kombinasi sebagai Logika Bisnis dan harus disimpan dalam Transaksi. Mohon sebarkan beberapa cahaya tambahan tentang ini.

— Mark Macneil Bikeio

Hai Rahul, jika saya mengerti Anda dengan benar, maka Anda benar. Operasi CRUD pada dasarnya adalah bagian atom dari transaksi bisnis. Saya pribadi lebih suka menggunakan mapper OR kuat seperti Hibernate sebagai repositori daripada membangun sendiri. Itu karena hibernate sudah mengimplementasikan satuan pola kerja secara internal. Juga saya biasanya menempatkan transaksi bisnis ke dalam layanan bisnis yang terpisah.

— Frank

Untuk model tampilan saya dapat memberi Anda contoh berikut: Hanya gambar Anda memiliki GUI dengan tampilan daftar ganda di dalamnya. Tampilan daftar-ganda ini menggunakan model tampilan daftar-ganda sebagai datamodelnya. Datamodel ini hanyalah komposisi dari dua daftar sederhana. Jadi dual-list-view-model tergantung pada implementasi layer presentasi karena ini bukan bagian dari model domain Anda, tidak seperti dua daftar sederhana yang digunakan untuk membuat view-model. Bergantung pada GUI yang ingin Anda buat, ada beberapa kasus di mana Anda mungkin ingin mengikat model tampilan tertentu ke tampilan, bukan model domain Anda.

— Frank

Bagian aturan / logika bisnis agak sulit dijelaskan. Untuk memulai pemrosesan data apa pun, Anda memanggil metode dari salah satu layanan Anda. Itu berarti Anda pada dasarnya memulai transaksi. Jika metode ini mengandung logika bisnis daripada disebut "skrip transaksi". Itu biasanya hal yang buruk karena hampir tidak dapat digunakan kembali. Akan lebih baik jika metode ini menyebut logika bisnis model domain Anda. Ini berarti bahwa model domain Anda harus dirancang sedemikian rupa sehingga dapat mengandung logika bisnis. Pendekatan berbasis domain ini tidak akan berfungsi dengan model domain yang tidak lengkap atau salah.

— Frank

73

Logika bisnis jangka menurut saya bukan definisi yang tepat. Evans berbicara dalam bukunya, Domain Driven Design, tentang dua jenis logika bisnis:

Logika domain.
Logika aplikasi.

Pemisahan ini menurut saya jauh lebih jelas. Dan dengan kesadaran bahwa ada berbagai jenis aturan bisnis juga muncul kesadaran bahwa mereka tidak semua harus pergi ke tempat yang sama.

Logika domain adalah logika yang sesuai dengan domain aktual. Jadi jika Anda membuat aplikasi akuntansi, maka aturan domain akan menjadi aturan mengenai akun, posting, perpajakan, dll. Dalam alat perencanaan perangkat lunak tangkas, aturannya akan seperti menghitung tanggal rilis berdasarkan kecepatan dan poin cerita di backlog, dll.

Untuk kedua jenis aplikasi ini, impor / ekspor CSV mungkin relevan, tetapi aturan impor / ekspor CSV tidak ada hubungannya dengan domain sebenarnya. Jenis logika ini adalah logika aplikasi.

Logika domain pasti masuk ke lapisan model. Model ini juga sesuai dengan lapisan domain di DDD.

Namun aplikasi logika tidak harus ditempatkan di lapisan model. Itu bisa ditempatkan di pengontrol secara langsung, atau Anda bisa membuat lapisan aplikasi terpisah dengan aturan itu. Apa yang paling logis dalam hal ini akan tergantung pada aplikasi yang sebenarnya.

— Pete
sumber

1

Ini sangat benar! Ada dua model di sini Model Tampilan Anda dan Model Domain Anda. Saya pikir hampir disayangkan bahwa tata letak proyek-proyek MVC membuat pengembang pemula percaya bahwa mereka harus menjejalkan kode mereka ke dalam Model Tampilan.

— Jonathan

1

Menemukan jawaban Anda lebih dapat diterima dan dimengerti. Terima kasih.

— revo

27

A1 : Logika Bisnis masuk ke Modelbagian dalam MVC. Peranannya Modeladalah memuat data dan logika bisnis. Controllerdi sisi lain bertanggung jawab untuk menerima input pengguna dan memutuskan apa yang harus dilakukan.

A2 : A Business Ruleadalah bagian dari Business Logic. Mereka memiliki has ahubungan. Business Logictelah Business Rules.

Lihatlah Wikipedia entry for MVC. Pergi ke Ikhtisar di mana ia menyebutkan aliranMVC pola.

Lihat juga Wikipedia entry for Business Logic. Disebutkan bahwa Business Logicitu terdiri dari Business Rulesdan Workflow.

— decyclone
sumber

16

Seperti yang ditunjukkan oleh beberapa jawaban, saya percaya ada beberapa kesalahpahaman arsitektur multi tier vs MVC.

Arsitektur multi tier melibatkan memecah aplikasi Anda menjadi tingkatan / lapisan (mis. Presentasi, logika bisnis, akses data)

MVC adalah gaya arsitektur untuk lapisan presentasi aplikasi. Untuk aplikasi yang tidak sepele, logika bisnis / aturan bisnis / akses data tidak boleh ditempatkan langsung ke dalam Model, Tampilan, atau Pengontrol. Untuk melakukannya akan menempatkan logika bisnis di lapisan presentasi Anda dan dengan demikian mengurangi penggunaan kembali dan pemeliharaan kode Anda.

Model adalah pilihan pilihan yang sangat masuk akal untuk menempatkan logika bisnis, tetapi pendekatan yang lebih baik / lebih dapat dipertahankan adalah memisahkan lapisan presentasi Anda dari lapisan logika bisnis Anda dan membuat lapisan logika bisnis dan cukup memanggil lapisan logika bisnis dari model Anda bila diperlukan. Lapisan logika bisnis pada gilirannya akan memanggil ke lapisan akses data.

Saya ingin menunjukkan bahwa tidak jarang menemukan kode yang menggabungkan logika bisnis dan akses data di salah satu komponen MVC, terutama jika aplikasi tidak dirancang menggunakan beberapa tingkatan. Namun, di sebagian besar aplikasi perusahaan, Anda biasanya akan menemukan arsitektur multi-tier dengan arsitektur MVC di dalam lapisan presentasi.

— treefiddy
sumber

2

Jawaban terbaik untuk masalah ini. Harus dinilai lebih tinggi. Jawaban terburuk ditandai sebagai diterima.

— Peter Matisko

Jawaban terbaik .. tidak diragukan

— salman

Apakah ini tergantung pada ukuran data dan aplikasi? Untuk aplikasi kecil, saya menduga semua logika bisa masuk ke model tanpa kebingungan. Jika demikian, berapa ambang ukuran untuk mulai memisahkan menjadi lapisan yang terpisah?

— mLstudent33

15

Ini adalah pertanyaan yang dijawab, tetapi saya akan memberikan "satu sen" saya:

Aturan bisnis termasuk dalam model. "Model" selalu terdiri dari (dipisahkan secara logis atau fisik):

model presentasi - satu set kelas yang sangat cocok untuk digunakan dalam tampilan (itu disesuaikan dengan UI / presentasi tertentu),
model domain - bagian UI-independen dari model, dan
repositori - bagian penyimpanan-sadar dari "model".

Aturan bisnis hidup dalam model domain, diekspos dalam bentuk presentasi-cocok untuk model "presentasi" dan kadang-kadang digandakan (atau juga ditegakkan) di "lapisan data".

— G. Stoynev
sumber

5

Tidak masuk akal untuk menempatkan lapisan bisnis Anda di Model untuk proyek MVC.

Katakan bahwa bos Anda memutuskan untuk mengubah lapisan presentasi ke hal lain, Anda akan kacau! Lapisan bisnis harus merupakan perakitan terpisah. Model berisi data yang berasal dari lapisan bisnis yang lolos ke tampilan untuk ditampilkan. Kemudian pada postingan misalnya, model mengikat kelas Person yang berada di lapisan bisnis dan memanggil PersonBusiness.SavePerson (p); di mana p adalah kelas Person. Inilah yang saya lakukan (kelas BusinessError hilang tetapi akan masuk ke BusinessLayer juga):

— Alex
sumber

Apakah Anda akan mengklarifikasi pernyataan ini? " Model berisi data yang berasal dari lapisan bisnis yang lolos ke tampilan untuk ditampilkan."

— Anthony Rutledge

2

Q1:

Logika bisnis dapat dipertimbangkan dalam dua kategori:

Logika domain menyukai kontrol pada alamat email (keunikan, kendala, dll.), Memperoleh harga suatu produk untuk faktur, atau, menghitung harga total shoppingCart berdasarkan objek produknya.
Alur kerja yang lebih luas dan rumit yang disebut proses bisnis, seperti mengendalikan proses pendaftaran untuk siswa (yang biasanya mencakup beberapa langkah dan memerlukan pemeriksaan yang berbeda dan memiliki kendala yang lebih rumit).

The pertama kategori masuk ke Model dan kedua satu milik kontroler . Ini karena kasus-kasus dalam kategori kedua adalah logika aplikasi luas dan menempatkannya dalam model dapat mencampur abstraksi model (misalnya, tidak jelas apakah kita perlu menempatkan keputusan itu dalam satu kelas model atau yang lain, karena mereka terkait untuk keduanya!).

Lihat jawaban ini untuk perbedaan khusus antara model dan pengontrol, tautan ini untuk definisi yang sangat tepat dan juga tautan ini untuk contoh Android yang bagus.

Intinya adalah bahwa catatan yang disebutkan oleh "Mud" dan "Frank" di atas keduanya bisa benar dan juga "Pete" (logika bisnis dapat dimasukkan ke dalam model, atau controller, sesuai dengan jenis logika bisnis).

Akhirnya, perhatikan bahwa MVC berbeda dari konteks ke konteks. Misalnya, dalam aplikasi Android, beberapa definisi alternatif disarankan yang berbeda dari yang berbasis web (lihat posting ini misalnya).

Q2:

Logika bisnis lebih umum dan (seperti "decyclone" yang disebutkan di atas) kami memiliki hubungan berikut di antaranya:

aturan bisnis ⊂ logika bisnis

— Alisa
sumber

0

Mengapa Anda tidak memperkenalkan lapisan layanan. maka controller Anda akan menjadi ramping dan lebih mudah dibaca, maka semua fungsi controller Anda akan menjadi tindakan murni. Anda dapat menguraikan logika bisnis sebanyak yang Anda butuhkan di dalam lapisan layanan. penggunaan kembali kode tinggi. tidak berdampak pada model dan repositori.

— Anil
sumber

-5

Model = kode untuk operasi basis data CRUD.

Pengendali = merespons tindakan pengguna, dan meneruskan permintaan pengguna untuk pengambilan data atau menghapus / memperbarui model, tunduk pada aturan bisnis khusus untuk suatu organisasi. Aturan bisnis ini dapat diimplementasikan dalam kelas pembantu, atau jika tidak terlalu rumit, langsung saja dalam tindakan pengontrol. Pengontrol akhirnya meminta pandangan untuk memperbarui dirinya sendiri sehingga dapat memberikan umpan balik kepada pengguna dalam bentuk tampilan baru, atau pesan seperti 'diperbarui, terima kasih', dll.,

View = UI yang dihasilkan berdasarkan kueri pada model.

Tidak ada aturan yang keras dan cepat mengenai ke mana aturan bisnis harus pergi. Dalam beberapa desain mereka masuk ke model, sedangkan yang lain mereka disertakan dengan controller. Tapi saya pikir lebih baik menyimpannya dengan controller. Biarkan model hanya khawatir tentang konektivitas basis data.

— Hoven
sumber

Jika Anda memasukkan aturan bisnis ke dalam pengontrol dan Anda memiliki banyak, banyak tindakan - apakah Anda akan meniru aturan bisnis itu berkali-kali? Tidak. Anda akan memisahkannya dalam metode helper atau semacamnya. Masukkan "benda" itu ke dalam model, di mana tempatnya.

— G. Stoynev

3

MVC bukan pola aplikasi untuk operasi basis data CRUD (meskipun dapat digunakan dengan cara itu) karena itu Model tidak dapat menjadi "kode untuk operasi basis data CRUD". Model mendefinisikan entitas aplikasi, termasuk data dan aturan bisnis. Pengontrol mengoordinasikan interaksi antara tampilan dan model. Tampilan adalah antarmuka pengguna yang mengekspos model dan operasi yang tersedia dalam model yang diekspos oleh pengontrol.

— Jon Davis