ASP.NET MVC - Haruskah logika bisnis ada di pengontrol?


97

Derik Whitaker memposting artikel beberapa hari yang lalu yang menyentuh titik yang membuat saya penasaran selama beberapa waktu: haruskah logika bisnis ada di pengontrol?

Sejauh ini semua demo ASP.NET MVC yang pernah saya lihat menempatkan akses repositori dan logika bisnis di pengontrol. Beberapa bahkan melempar validasi ke sana juga. Ini menghasilkan pengendali yang cukup besar dan membengkak. Apakah ini benar-benar cara menggunakan kerangka MVC? Tampaknya ini hanya akan berakhir dengan banyak kode dan logika duplikat yang tersebar di berbagai pengontrol.


Tautan ke artikel sudah mati - web.archive.org/web/20150906064521/http://devlicio.us/blogs/… adalah salinan dari archive.org untuk siapa pun yang tertarik.
Stuart Moore

Jawaban:


75

Logika bisnis harus benar-benar ada dalam modelnya. Anda harus membidik model gemuk, pengontrol kurus.

Misalnya, daripada memiliki:

public interface IOrderService{
    int CalculateTotal(Order order);
}

Saya lebih suka memiliki:

public class Order{
    int CalculateTotal(ITaxService service){...}        
}

Ini mengasumsikan bahwa pajak dihitung oleh layanan eksternal, dan mengharuskan model Anda mengetahui tentang antarmuka ke layanan eksternal Anda.

Ini akan membuat pengontrol Anda terlihat seperti:

public class OrdersController{
    public OrdersController(ITaxService taxService, IOrdersRepository ordersRepository){...}

    public void Show(int id){
        ViewData["OrderTotal"] = ordersRepository.LoadOrder(id).CalculateTotal(taxService);
    }
}

Atau semacam itu.


1
Jadi, apakah Anda akan menyuntikkan Layanan ke pengontrol Anda, bukan ke repositori? Bagaimana prinsip Unit Kerja berperan dalam kasus itu?
Kevin Pang

Saya menulis beberapa hal lagi, saya harap ini lebih masuk akal. Anda mungkin juga ingin membaca: weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model Meskipun ini tentang Rails, ini masih sangat bisa diterapkan.
jonnii

Saya akan menyebut repositori sebagai layanan, secara pribadi.
Brad Wilson

Mereka pasti semacam layanan, tetapi secara khusus untuk akses data. Itu hanya konvensi yang saya gunakan, bukan sesuatu yang saya dukung secara khusus.
jonnii

1
Ini akan membuat model Anda dipasangkan erat dengan ITaxService. Jika Anda ingin menggunakan kembali model di proyek lain atau dll lain, Anda harus memiliki implementasi atau referensi ITaxService, jika tidak model Anda akan rusak, yang mengakibatkan pelanggaran prinsip SOLID. ITaxService harus memiliki referensi model Anda. Dengan cara ini, Anda dapat menggunakan kembali model Anda di proyek lain tanpa memerlukan referensi ITaxService.
Mehmet Ali Sert

65

Saya suka diagram yang disajikan oleh Microsoft Patterns & Practices . Dan saya percaya pada pepatah 'Sebuah gambar bernilai seribu kata'.

Diagram menunjukkan arsitektur MVC dan lapisan layanan bisnis


6
Itu sangat berguna! Bisakah Anda memberi tahu saya di mana di situs itu Anda menemukan diagram ini?
Rob Church

2
Ini dari 'Implementasi Sisi Server' Microsoft msdn.microsoft.com/en-us/library/hh404093.aspx
Justin

Oke, tetapi dalam, katakanlah, aplikasi MVC - ke mana perginya logika bisnis? Sepertinya kita membutuhkan lapisan layanan tambahan atau sesuatu ?!
niico

14

Ini pertanyaan yang menarik.

Saya pikir yang menarik bahwa sejumlah besar contoh aplikasi MVC benar-benar gagal mengikuti paradigma MVC dalam arti benar-benar menempatkan "logika bisnis" seluruhnya dalam model. Martin Fowler telah menunjukkan bahwa MVC bukanlah pola dalam pengertian Gang Of Four. Sebaliknya, itu adalah paradigma bahwa programmer harus menambahkan pola untuk jika mereka menciptakan sesuatu di luar aplikasi mainan.

Jadi, jawaban singkatnya adalah bahwa "logika bisnis" seharusnya tidak tinggal di controller, karena controller memiliki fungsi tambahan untuk menangani tampilan dan interaksi pengguna dan kita ingin membuat objek hanya dengan satu tujuan.

Jawaban yang lebih panjang adalah Anda perlu memikirkan desain lapisan model Anda sebelum memindahkan logika dari pengontrol ke model. Mungkin Anda dapat menangani semua logika aplikasi menggunakan REST, dalam hal ini desain model harus cukup jelas. Jika tidak, Anda harus tahu pendekatan apa yang akan Anda gunakan agar model Anda tidak membengkak.


14

Anda dapat memeriksa tutorial mengagumkan ini oleh Stephen Walther yang menunjukkan Memvalidasi dengan Lapisan Layanan .

Pelajari cara memindahkan logika validasi dari tindakan pengontrol Anda ke lapisan layanan terpisah. Dalam tutorial ini, Stephen Walther menjelaskan bagaimana Anda dapat mempertahankan pemisahan tajam masalah dengan mengisolasi lapisan layanan Anda dari lapisan pengontrol.


2
Ini jawaban yang paling benar. Saya pribadi menganjurkan lebih lanjut untuk tidak mengekspos layanan ke controller, sebagai gantinya memilih untuk menggunakan konsep ViewModel seperti yang ditemukan dalam pola MVVM. Bayangkan sebuah skenario di mana Anda ingin menulis aplikasi bisnis dengan antarmuka desktop (katakanlah, formulir windows atau WPF) dan juga antarmuka web. Memecahkan masalah itu membawa Anda ke pola "pengontrol kurus" seperti yang juga dianjurkan di sini. Intinya: jangan pernah menempatkan logika bisnis dalam model atau pengontrol dan jangan meletakkan apa pun di pengontrol yang tidak Anda miliki juga.
Sam

9

Logika Bisnis tidak boleh terkandung dalam pengontrol. Pengontrol harus sekurus mungkin, idealnya mengikuti derai:

  1. Temukan entitas domain
  2. Bertindak atas entitas domain
  3. Siapkan data untuk melihat / mengembalikan hasil

Selain itu, pengontrol dapat berisi beberapa logika aplikasi.

Jadi di mana saya meletakkan logika bisnis saya? Dalam Model.

Apa Model? Nah, itu pertanyaan yang bagus. Silakan lihat artikel Pola dan Praktik Microsoft (pujian untuk AlejandroR untuk penemuan yang sangat baik). Di sini ada tiga kategori model:

  • Model Tampilan : Ini hanyalah kantong data, dengan logika minimal, jika ada, untuk meneruskan data dari dan ke tampilan, berisi validasi bidang dasar.
  • Model Domain : Model gemuk dengan logika bisnis, beroperasi pada satu atau beberapa entitas data (yaitu entitas A dalam keadaan tertentu daripada tindakan pada entitas B)
  • Model Data : Model sadar penyimpanan, logika yang terkandung dalam satu entitas hanya berhubungan dengan entitas itu (yaitu jika bidang a maka bidang b)

Tentu saja, MVC adalah paradigma yang hadir dalam variasi yang berbeda. Yang saya jelaskan di sini adalah MVC menempati lapisan atas saja, vide artikel ini di Wikipedia

Saat ini, MVC dan model-view-presenter (MVP) yang serupa adalah pola desain Pemisahan Kekhawatiran yang berlaku secara eksklusif untuk lapisan presentasi dari sistem yang lebih besar. Dalam skenario sederhana MVC dapat mewakili desain utama sistem, menjangkau langsung ke database; namun, di sebagian besar skenario, Pengontrol dan Model di MVC memiliki ketergantungan yang longgar pada lapisan / tingkatan Layanan atau Data. Ini semua tentang arsitektur Client-Server


-1

Jika Anda menggunakan Dependency Injectors, logika bisnis Anda akan menuju ke sana dan karenanya Anda akan mendapatkan pengontrol yang rapi dan bersih.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.