Di mana menempatkan logika bisnis dalam desain MVC?

Saya telah membuat aplikasi Java MVC sederhana yang menambahkan catatan melalui formulir data ke database.

Aplikasi saya mengumpulkan data, juga memvalidasi dan menyimpannya. Ini karena data bersumber online dari pengguna yang berbeda. sebagian besar data bersifat numerik.

Sekarang pada data numerik yang disimpan ke dalam basis data (SQL server), saya ingin aplikasi saya melakukan perhitungan dan menampilkan hasilnya. Pengguna tidak tertarik pada bagaimana perhitungan dilakukan sehingga harus dienkapsulasi. Pengguna hanya harus dapat melihat data yang dihitung sederhana (misalnya, data kolom dikurangi B data kolom dibagi dengan data kolom C). Saya tahu cara menulis prosedur tersimpan untuk hal yang sama tetapi saya ingin aplikasi tiga tingkat.

Saya ingin data yang saya masukkan ke dalam database sebagai catatan, dikerjakan dengan melakukan perhitungan di dalamnya. Data asli harus tetap tidak terpengaruh, sedangkan data baru, setelah kalkulasi, harus disimpan sebagai catatan entitas baru ke dalam database.

Di mana saya harus menulis kode untuk perhitungan latar belakang ini? Karena aturan dan logika bisnis, haruskah saya memasukkannya ke file JavaBeans baru?

— BriskLabs Pakistan
sumber

kemungkinan duplikat dari Tetap OO dan Dapat Diuji saat bekerja dengan database

— agas

Jawaban:

The logika bisnis harus ditempatkan dalam model yang , dan kita harus bertujuan untuk lemak model dan kurus pengendali .

Sebagai titik awal, kita harus mulai dari logika controller. Sebagai contoh: saat pembaruan , controller Anda harus mengarahkan kode Anda ke metode / layanan yang memberikan perubahan Anda ke model.

Dalam model, kita dapat dengan mudah membuat kelas pembantu / layanan tempat aturan atau perhitungan bisnis aplikasi dapat divalidasi.

Ringkasan konseptual

Pengontrol untuk logika aplikasi. Logika yang khusus untuk bagaimana aplikasi Anda ingin berinteraksi dengan "domain pengetahuan" yang dimilikinya.
The model untuk logika yang independen dari aplikasi . Logika ini harus valid di semua aplikasi yang memungkinkan dari "domain pengetahuan" yang dimilikinya.
Dengan demikian, logis untuk menempatkan semua aturan bisnis dalam model.

— EL Yusubov
sumber

jawaban yang jelas dan ringkas yang bagus ..

— hanzolo

@Yusubov, bisakah Anda menjelaskan kepada saya perbedaan antara logika aplikasi dan logika bisnis

— Mohamad

@Moh, Singkatnya, ini adalah kata-kata buzz untuk membantu menggambarkan tingkatan teknologi dalam suatu aplikasi. Logika bisnis pada dasarnya adalah aturan sistem sesuai dengan spesifikasi fungsional. Misalnya Objek A tipe B harus dikaitkan C dan D, tetapi tidak E. Logika Aplikasi lebih dari spesifikasi teknis, seperti menggunakan Java servlets dan OJB untuk bertahan ke database Oracle.

— EL Yusubov

Tolong uraikan kata-kata ini:

The most common mistakes are to implement application logic operations inside the controller or the view(presentation) layer.

[ php-html.net/tutorials/model-view-controller-in-php ]

— revo

Jika saya mengerti benar, artikel yang disebutkan merujuk pada 'logika aplikasi' sebagai 'logika bisnis'. Dengan demikian, segala sesuatu yang mengacu pada logika bisnis tidak boleh ditempatkan di controller atau view.

— EL Yusubov

Seperti biasa, itu tergantung pada kompleksitas proyek.

Dalam aplikasi sepele, di mana kompleksitas model domain relatif kecil, Anda dapat menempatkan logika dalam model dan menyebutnya sehari.

Namun, untuk aplikasi yang tidak sepele dengan model yang rumit dan banyak aturan bisnis, lebih baik untuk memisahkan beberapa hal lebih sedikit.

Jika Anda memasukkan logika bisnis yang melibatkan lebih dari satu model dalam suatu model, Anda memperkenalkan hubungan yang erat antara model-model itu. Ketika aplikasi terus tumbuh, model ini cenderung berubah menjadi god models, tahu terlalu banyak. Dan ini akan dengan cepat berubah menjadi kekacauan besar yang sulit untuk diuji dan dirawat. Jadi dalam hal ini, akan bermanfaat untuk menempatkan logika di lapisan yang terpisah.

Saat memutuskan abstraksi, selalu pertimbangkan kompleksitas dan tujuan aplikasi Anda, dan hindari rekayasa berlebihan. Untuk aplikasi sepele / kecil, memperkenalkan lebih banyak layer daripada yang dibutuhkan meningkatkan kompleksitas alih-alih menguranginya.

Robert Martin (Paman Bob) memiliki posting blog yang bagus tentang hal ini: Arsitektur Bersih.

— Hakan Deryal
sumber

pertanyaannya khusus untuk MVC. logika bisnis harus selalu ada dalam model. Kontroler hanyalah sebuah adaptor.

— jgauffin

MVC adalah salah satu istilah yang paling kelebihan dalam industri. Saya tidak ingin mendapatkan keunikan dari istilah ini, karena menjamin buku. Hanya saja, menggunakan MVC tidak menyiratkan bahwa Anda harus memasukkan setiap logika dalam model.

— Hakan Deryal

Dari definisi oleh Steve Burbeck (tim Smalltalk):

The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate

. Itu definisi adaptor.

— jgauffin

Jika Anda memasukkan semua logika dalam model, Anda akan berakhir dengan ribuan baris kekacauan yang tidak dapat dipertahankan. Pernah ke sana. Bukan dosa memiliki kelas utilitas dan lapisan layanan.

— asthasr

Saya pikir apa yang didapat dari jgauffin adalah bahwa pertanyaannya khusus untuk MVC. Jika kami setuju untuk melihat sistem dari perspektif MVC dan hanya dari perspektif MVC, maka ya, semua logika bisnis termasuk dalam "model", tetapi "model" dapat mencakup beberapa kelas dan lapisan, termasuk "kelas utilitas" dan "lapisan layanan". Dengan kata lain, kita tidak akan mengatakan lapisan layanan adalah bagian dari pengontrol atau tampilan, oleh karena itu yang paling cocok adalah model.

— DavidS

Menempatkan logika bisnis di dalam model mungkin terdengar cara terbaik untuk pergi. Pengontrol menerima panggilan dari aplikasi web jarak jauh. Pengontrol pada layanan web MVC menerima panggilan dan mengalihkan eksekusi ke metode di BL. Sekarang, Logika Bisnis dapat dimasukkan dalam 'Model', tetapi juga dapat diposisikan di beberapa folder lain, katakanlah, 'Logika Bisnis' . Jadi tidak ada aturan yang sulit dan cepat tentang di mana logika bisnis akan berada.

Saya telah menggunakan layanan web yang dibangun di atas MVC 3.0 dan wadah logika bisnis adalah MVC MODEL .

— MontyPython
sumber

Saya setuju. Anda mendapatkan aplikasi yang jauh lebih fleksibel ketika model Anda hanyalah sebuah struktur data yang ditindaklanjuti oleh kelas logika bisnis lainnya. Sebagai contoh sederhana, saya pikir itu adalah kegagalan besar pendekatan ASP.NET untuk validasi dengan menggunakan atribut. Jika saya membubuhi keterangan properti FirstName seseorang dengan atribut yang diperlukan, apa yang terjadi jika saya membuat tampilan admin di mana FirstName tidak diperlukan? Lapisan logika bisnis harus mengkonsumsi model dan menentukan tindakan yang sesuai untuk itu.

— xr280xr