ASP.NET MVC - Denetleyicilerde iş mantığı olmalı mı?

Derik Whitaker , birkaç gün önce bir süredir merak ettiğim bir noktaya denk gelen bir makale yayınladı : kontrolörlerde iş mantığı olmalı mı?

Şimdiye kadar gördüğüm tüm ASP.NET MVC demoları, denetleyiciye depo erişimi ve iş mantığı koydu. Hatta bazıları oraya doğrulama bile atıyor. Bu oldukça büyük, şişirilmiş denetleyicilerle sonuçlanır. MVC çerçevesini kullanmanın yolu gerçekten bu mu? Görünüşe göre bu, farklı denetleyicilere yayılmış çok sayıda yinelenen kod ve mantıkla sonuçlanacak.

İş mantığı gerçekten modelde olmalıdır. Şişman modeller, sıska kontrolörler hedeflemelisiniz.

Örneğin, sahip olmak yerine:

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

İsterim:

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

Bu, verginin harici bir hizmet tarafından hesaplandığını varsayar ve modelinizin harici hizmetlerinize yönelik arayüzler hakkında bilgi sahibi olmasını gerektirir.

Bu, denetleyicinizin şöyle görünmesini sağlar:

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

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

Ya da böyle bir şey.

Microsoft Patterns & Practices tarafından sunulan diyagramı beğendim . Ve 'Bir resim bin kelimeye bedeldir' atasözüne inanıyorum.

Bu büyüleyici bir soru.

Bence çok sayıda örnek MVC uygulamasının, "iş mantığını" tamamen modele gerçekten yerleştirme anlamında MVC paradigmasını takip edememesi ilginç. Martin Fowler, MVC'nin Gang Of Four anlamında bir model olmadığına işaret etti. Daha ziyade, programcı desenleri eklemeniz gerekir paradigma olduğu için onlar bir oyuncak app ötesinde bir şey yaratma eğer.

Bu nedenle, kısa cevap, "iş mantığının" denetleyicide gerçekten yaşamaması gerektiğidir, çünkü denetleyicinin görünüm ve kullanıcı etkileşimleriyle ilgilenme ek işlevi vardır ve biz sadece tek bir amaçla nesneler oluşturmak istiyoruz.

Daha uzun bir cevap, mantığı denetleyiciden modele taşımadan önce model katmanınızın tasarımına biraz düşünmeniz gerektiğidir. Belki de tüm uygulama mantığını REST kullanarak halledebilirsiniz, bu durumda modelin tasarımı oldukça net olmalıdır. Değilse, modelinizin şişmesini önlemek için hangi yaklaşımı kullanacağınızı bilmelisiniz.

Hizmet Katmanı ile Doğrulama'yı gösteren bu harika öğreticiye Stephen Walther tarafından bakabilirsiniz .

Doğrulama mantığınızı denetleyici eylemlerinizden ayrı bir hizmet katmanına nasıl taşıyacağınızı öğrenin. Bu eğitimde Stephen Walther, hizmet katmanınızı denetleyici katmanınızdan ayırarak endişelerinizi nasıl keskin bir şekilde ayırabileceğinizi açıklıyor.

İş Mantığı, denetleyicilere dahil edilmemelidir. Kontrolörler olabildiğince zayıf olmalı, ideal olarak pıtırtı izleyin:

1. Etki alanı varlığını bulun
2. Etki alanı varlığına göre hareket et
3. Sonuçları görüntülemek / döndürmek için verileri hazırlayın

Ek olarak denetleyiciler bazı uygulama mantığını içerebilir.

Peki iş mantığımı nereye koymalıyım? Modelde.

Model nedir? Şimdi bu iyi bir soru. Lütfen Microsoft Kalıplar ve Uygulamalar makalesine bakın (mükemmel bulmak için AlejandroR'a övgü). Burada üç model kategorisi vardır:

• Modeli Görüntüle : Bu, basitçe bir veri torbasıdır, eğer varsa, verileri görünümlerden ve görünümlere aktarmak için minimum mantık, temel alan doğrulamasını içerir.
• Etki Alanı Modeli : İş mantığına sahip şişman model, tek veya birden fazla veri varlığında çalışır (yani, belirli bir durumda A varlığı, B varlığı üzerindeki eylemden daha çok)
• Veri Modeli : Depolamaya duyarlı model, tek bir varlık içinde bulunan mantık yalnızca o varlıkla ilgilidir (yani, eğer a alanı ise b alanı)

Elbette MVC, farklı çeşitlerde gelen bir paradigmadır. Burada anlattığım şey MVC'nin yalnızca üst katmanı işgal ettiği , Wikipedia'daki bu makaleye bakın

Bugün, MVC ve benzer model-görünüm-sunucu (MVP), yalnızca daha büyük bir sistemin sunum katmanına uygulanan Kaygı Ayrımı tasarım kalıplarıdır. Basit senaryolarda MVC, doğrudan veri tabanına ulaşan bir sistemin birincil tasarımını temsil edebilir; ancak, çoğu senaryoda, MVC'deki Denetleyici ve Model, bir Hizmet veya Veri katmanına / katmanına gevşek bir bağımlılığa sahiptir. Bu tamamen İstemci-Sunucu mimarisi ile ilgili

Bağımlılık Enjektörlerini kullanırsanız, iş mantığınız onlara gidecek ve dolayısıyla düzgün ve temiz denetleyiciler alacaksınız.