Şişman modeller ve sıska denetleyiciler, Tanrı modelleri yaratmak gibi geliyor [kapalı]

Özellikle şişman modellerin ve zayıf kontrolcülerin yaklaşımını savunan birçok blog okuyorum . Rails kampı. Sonuç olarak, yönlendiriciler temelde hangi denetleyicide hangi yöntemin çağrılacağını bulmakta ve denetleyici yönteminin yaptığı tüm modelde karşılık gelen yöntemi çağırmak ve ardından görünümü ortaya çıkarmaktır. Yani burada anlamadığım iki endişem var:

1. Denetleyici ve yönlendirici, rotaya dayalı Tanrı benzeri modelde bir yöntem çağırmaktan başka gerçekten çok farklı görevler yapmıyor.
2. Modeller çok şey yapıyor. E-postalar göndermek, ilişkiler oluşturmak, diğer modelleri silmek ve değiştirmek, görevleri sıraya koymak, vb. Temelde artık, verileri modelleme ve işlemeyle ilgili olabilecek veya olmayabilecek her şeyi yapması beklenen Tanrı benzeri nesnelere sahipsiniz.

Çizgiyi nereye çekiyorsun? Bu sadece Tanrı modeline girmiyor mu?

_{Rails'e MVC tasarım modelinin bir parçası olarak bakmak en iyi fikir olmayabilir. Söz konusu çerçeve bazı içsel eksikliklerle oluşturulmuştu (bunu farklı bir yazıda ayrıntılı olarak açıkladım ) ve topluluk ancak şimdi bu sonuçları ele almaya başladı. DataMapper2 geliştirmeye ilk büyük adım olarak bakabilirsiniz .}

Bazı teori

Bu tavsiyeyi veren insanlar, oldukça yaygın bir yanlış anlamadan etkilenmiş gibi görünüyor. Öyleyse açıklayarak başlayayım: Modern MVC tasarım modelinde model bir sınıf veya nesne DEĞİLDİR. Model bir katmandır.

MVC modelinin arkasındaki temel fikir Ayrılık Kaygılarıdır ve bunun ilk adımı sunum katmanı ile model katmanları arasındaki bölünmedir. Tıpkı sunum katmanının denetleyicilere (kullanıcı girdisiyle ilgilenmekten sorumlu örnekler), görünümlere (örnekler, UI mantığından sorumlu örnekler) ve şablonlara / düzenlere bölünmesi gibi, model katmanı da öyle.

Model katmanının içerdiği ana parçalar şunlardır:

• Etki Alanı Nesneleri

  Etki alanı varlıkları, iş nesneleri veya model nesneleri olarak da bilinir (Bu ikinci adı sevmiyorum çünkü karışıklığa katkıda bulunuyor). Bu yapılar, insanların genellikle yanlışlıkla "model" dedikleri yapılardır. İş kurallarını içermekten sorumludurlar (belirli alan mantığı birimi için tüm matematik ve doğrulama).

• Depolama Soyutlamaları:

  Genellikle veri eşleyici modeli kullanılarak uygulanır ( bu adı kötüye kullanan ORM'lerle karıştırmayın ). Bu örneklere genellikle, etki alanı nesnelerinden bilgi depolama ve bunlara erişim ile görev verilir. Her etki alanı nesnesi, çeşitli depolama biçimleri (DB, önbellek, oturum, tanımlama bilgileri, / dev / null) olduğu gibi birkaç eşleyiciye sahip olabilir.

• Hizmetler:

  Uygulama mantığından sorumlu yapılar (yani, etki alanı nesneleri arasındaki etkileşim ve etki alanı nesneleri ve depolama soyutlamaları arasındaki etkileşim). Sunum katmanının model katmanıyla etkileşime girdiği "arayüz" gibi davranmaları gerekir. Bu genellikle Rails benzeri kodda denetleyicilerde biten şeydir.

Bu gruplar arasındaki boşluklarda olabilecek birkaç yapı da vardır: DAO'lar , çalışma birimleri ve depolar .

_{Oh ... ve (web bağlamında) MVC uygulamasıyla etkileşime giren bir kullanıcı hakkında konuştuğumuzda , bu bir insan değil. "Kullanıcı" aslında web tarayıcınızdır.}

Peki ya tanrılar?

Üzerinde çalışmak için korkutucu ve yekpare bir modele sahip olmak yerine, denetleyiciler hizmetlerle etkileşim kurmalıdır. Kullanıcı girişinden belirli bir hizmete veri aktarırsınız (örneğin MailServiceveya RecognitionService). Bu şekilde denetleyici, model katmanının durumunu değiştirir, ancak bu, açık bir API kullanılarak ve dahili yapılarla uğraşmadan (sızıntılı bir soyutlamaya neden olur) yapılır.

Bu tür değişiklikler, bazı anlık tepkilere neden olabilir veya yalnızca görünüm örneğinin model katmanından istediği verileri veya her ikisini de etkileyebilir.

Her hizmet, herhangi bir sayıda (ancak, genellikle yalnızca bir avuç) etki alanı nesnesi ve depolama soyutlamalarıyla etkileşime girebilir. Örneğin RecogitionService, makaleler için depolama soyutlamaları ile daha az ilgilenemezler.

Kapanış notları

Bu şekilde, herhangi bir seviyede ünite testine tabi tutulabilen, düşük kuplajlı (doğru şekilde uygulandıysa) ve açıkça anlaşılır bir mimariye sahip bir uygulama elde edersiniz.

Yine de şunu unutmayın: MVC, küçük uygulamalar için tasarlanmamıştır. MVC kalıbını kullanarak bir ziyaretçi defteri sayfası yazıyorsanız, yanlış yapıyorsunuz demektir. Bu model, büyük ölçekli uygulamalarda yasa ve düzeni uygulamak içindir.

_{PHP'yi birincil dil olarak kullanan kişiler için bu gönderi alakalı olabilir. Birkaç kod parçacığı içeren model katmanının biraz daha uzun açıklaması.}

"Model" sınıfları yetersiz uygulanırsa, evet, endişeniz konuyla ilgilidir. Bir model sınıf E-posta (altyapı görevleri) yapmamalıdır.

Asıl soru, MVC'deki modelin ne anlama geldiğidir. Birkaç yöntemle POCO sınıflarıyla sınırlı değildir. MVC'deki model, Veri ve İş mantığı anlamına gelir. Klasik çekirdek POCO modellerinin bir üst kümesi olarak düşünün.

Görünüm ==== Denetleyici ==== Model -> İş Süreci katmanı -> Temel modeller

Altyapı derlemelerini ve Veri Erişim katmanlarını ekleyin ve bunu BPL'ye aktarmak için enjeksiyonu kullanın, ardından bir işleminiz MVC'yi amaçlandığı gibi kullanıyor.

BPL, UoW / Respository kalıplarını çağırabilir ve iş kurallarını yürütebilir ve enjekte edilen Nesneler veya arayüz kalıpları yoluyla Altyapı özelliklerini çağırabilir.

Dolayısıyla, bir denetleyiciyi zayıf tutma önerisi, klasik Core modelindeki "kişi" sınıfının 50 yönteme sahip olması ve doğrudan E-postayı çağırması gerektiği anlamına gelmez. Bunun yanlış olduğunu düşünmekte haklısın.

Denetleyicinin, doğrudan çağrılırsa, Altyapı sınıflarını BPL veya çekirdek katmana başlatması ve enjekte etmesi gerekebilir. Klasik Nesne modeli sınıflarında bir iş katmanı veya en azından çağrıları düzenleyen sınıflar olmalıdır. Zaten bu benim "görüşüm" ;-)

MVC'ye genel bakış için wiki açıklaması http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

MVC'deki "M" den bahseden Küçük Blog. http://www.thedeveloperday.com/skinny-controllers/

Tek bir yağ modeli (muhtemelen Uygulama veya Uygulama olarak adlandırılır) ile mantıksal gruplara (İş, Müşteri, Sipariş, Mesaj) ayrılmış birkaç yağ modeli arasında bir ayrım yapabileceğinizi düşünüyorum. İkincisi, uygulamalarımı nasıl yapılandırdığımdır ve her model kabaca ilişkisel bir veritabanındaki bir veritabanı tablosuna veya bir belge veritabanındaki bir koleksiyona karşılık gelir. Bu modeller, ister veritabanıyla konuşuyor ister bir API çağırıyor olsun, modeli oluşturan verileri oluşturmanın, güncellemenin ve değiştirmenin tüm yönlerini ele alır. Denetleyici, uygun modeli çağırmaktan ve bir şablon seçmekten çok az sorumludur.