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

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.

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.

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

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.

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.

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

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