MVC: Kontrolör Tek Sorumluluk İlkesini ihlal ediyor mu?

Tek Sorumluluk İlkesi "bir sınıfın değişimin bir nedeni olması gerektiğini" belirtir.

MVC modelinde, Kontrolcünün işi Görünüm ve Model arasında aracılık etmektir. Kullanıcı tarafından GUI üzerinde yapılan eylemleri rapor etmek için Görünüm için bir arayüz sunar (örneğin, Görünüm'ün çağrı yapmasına izin vermek controller.specificButtonPressed()) ve verilerini değiştirmek veya işlemlerini başlatmak için Model üzerinde uygun yöntemleri çağırabilir (örn. model.doSomething()) .

Bunun anlamı şudur ki:

• Denetleyiciye, kullanıcı işlemlerini bildirmek üzere uygun bir arabirim göstermesi için GUI hakkında bilgi sahibi olması gerekir.
• Ayrıca Model üzerinde uygun yöntemleri çağırabilmek için Modeldeki mantık hakkında bilgi sahibi olmak gerekir.

Bunun iki değişik nedeni olduğu anlamına gelir : GUI'de bir değişiklik ve iş mantığında bir değişiklik.

GUI değişirse, örneğin yeni bir düğme eklenirse, Kontrolörün Görünüm'ün bir kullanıcıyı rapor etmesine izin vermek için yeni bir yöntem eklemesi gerekebilir.

Modeldeki iş mantığı değişirse, Model üzerinde doğru yöntemleri çağırmak için Kontrolörün değişmesi gerekebilir.

Bu nedenle, Denetleyicinin değiştirmek için iki olası nedeni vardır . SRP'yi bozuyor mu?

Sonuç olarak SRP ile ilgili akıl yürütmeye devam ederseniz, "tek sorumluluk" un aslında süngerimsi bir terim olduğunu fark edeceksiniz. İnsan beynimiz bir şekilde farklı sorumlulukları ayırt edebiliyor ve çoklu sorumluluklar bir "genel" sorumluluk olarak soyutlanabiliyor. Örneğin, 4 kişilik ortak bir ailede kahvaltı yapmaktan sorumlu bir aile üyesi olduğunu düşünün. Şimdi, bunu yapmak için, yumurta ve tost ekmeği kaynatmalı ve tabii ki sağlıklı bir fincan yeşil çay kurmalı (evet, yeşil çay en iyisidir). Bu şekilde "kahvaltı yapmak", birlikte "kahvaltı yapmak" için soyutlanan küçük parçalara bölebilirsiniz. Her bir parçanın, örneğin başka birine devredilebilecek bir sorumluluk olduğuna dikkat edin.

MVC'ye dönersek: model ve görüş arasında aracılık yapmak bir sorumluluk değil iki sorumluluktursa, o zaman bu ikisini birleştiren yukarıdaki soyutlama katmanı ne olurdu? Birini bulamazsanız, ya doğru bir şekilde soyutlamadınız ya da hiçbir şey yoktur, bu da onu tamamladığınız anlamına gelir. Ve bir kontrolörde, bir görünümde ve bir modelde durum böyle hissediyorum.

Bir sınıfın "değiştirmek için iki nedeni" varsa, evet, SRP'yi ihlal eder.

Bir denetleyici genellikle hafif olmalı ve GUI tarafından yönlendirilen bazı olaylara yanıt olarak etki alanını / modeli manipüle etme konusunda tek sorumluluğa sahip olmalıdır. Bu manipülasyonların her birini temel olarak kullanım örnekleri veya özellikler olarak düşünebiliriz.

GUI'ye yeni bir düğme eklenirse, denetleyici yalnızca bu yeni düğme bazı yeni bir özelliği temsil ediyorsa (yani ekran 1'de var olan ancak henüz ekran 2'de mevcut olmayan aynı düğmenin aksine) değişmelidir. ekran 2'ye eklendi). Bu yeni işlevselliği / özelliği desteklemek için modelde buna karşılık gelen yeni bir değişiklik olması gerekecektir. Denetleyici hala GUI tarafından yönlendirilen bazı olaylara yanıt olarak etki alanını / modeli değiştirme sorumluluğuna sahiptir.

Modeldeki iş mantığı bir hatanın düzeltilmesi nedeniyle değişiyorsa ve denetleyicinin değişmesini gerektiriyorsa, bu özel bir durumdur (veya belki de model açık-kapalı prensibi ihlal etmektedir). Modeldeki iş mantığı bazı yeni işlevleri / özellikleri destekleyecek şekilde değişirse, denetleyiciyi mutlaka etkilemez - yalnızca denetleyicinin bu özelliği göstermesi gerekiyorsa (neredeyse her zaman böyle olur, aksi halde neden eklenir? kullanılmayacaksa alan modeli). Bu nedenle, bu durumda denetleyici, bazı GUI güdümlü olaylara yanıt olarak etki alanı modelinin bu yeni şekilde değiştirilmesini desteklemek için de değiştirilmelidir.

Denetleyicinin değişmesi gerekiyorsa, örneğin, kalıcılık katmanı düz bir dosyadan veritabanına değiştirildiğinde, denetleyici kesinlikle SRP'yi ihlal ediyor demektir. Denetleyici her zaman aynı soyutlama katmanında çalışıyorsa, bu SRP'ye ulaşmaya yardımcı olabilir.

Denetleyici SRP'yi ihlal etmiyor. Belirttiğiniz gibi, sorumluluğu modeller ve görüş arasında arabuluculuk yapmaktır.

Bununla birlikte, örneğinizle ilgili sorun, görünümde mantık için denetleyici yöntemleri bağlamanızdır controller.specificButtonPressed. Yöntemleri bu şekilde adlandırmak, denetleyiciyi GUI'nize bağlar, işleri düzgün bir şekilde soyutlayamadınız. Kontrolör belirli eylemler gerçekleştirmeyle ilgili olmalıdır, yani controller.saveDataveya controller.retrieveEntry. GUI'ye yeni bir düğme eklemek, denetleyiciye yeni bir yöntem eklemek anlamına gelmez.

Görünümde bir düğmeye basmak, bir şey yapmak anlamına gelir, ancak ne olursa olsun, başka herhangi bir sayıda kolayca tetiklenebilir veya hatta görünüm yoluyla değil.

SRP hakkındaki Wikipedia makalesinden

Martin bir sorumluluğu değişim nedeni olarak tanımlar ve bir sınıfın ya da modülün değiştirmek için sadece bir tane nedeni olması gerektiği sonucuna varır. Örnek olarak, bir raporu derleyen ve yazdıran bir modülü ele alalım. Böyle bir modül iki nedenden dolayı değiştirilebilir. İlk olarak, raporun içeriği değişebilir. İkinci olarak, raporun biçimi değişebilir. Bu iki şey çok farklı nedenlerle değişir; bir önemli ve bir kozmetik. Tek sorumluluk ilkesi, sorunun bu iki yönünün gerçekten iki ayrı sorumluluk olduğunu ve bu nedenle ayrı sınıflarda veya modüllerde olması gerektiğini söylüyor. Farklı zamanlarda farklı nedenlerle değişen iki şeyi birleştirmek kötü bir tasarım olurdu.

Denetleyici, yalnızca yöntemlerinden biri çağrıldığında görünüme belirtilen verileri sağlamasıyla ilgili görünümde olanlarla ilgilenmez. Sadece modelin işlevselliğini, sahip olacakları yöntemleri çağırması gerektiğini bildiği kadarıyla bilmelidir. Bundan daha fazlasını bilmiyor.

Bir nesnenin çağrılabilecek bir yöntemi olduğunu bilmek, işlevselliğini bilmekle aynı şey değildir.

Bir kontrolörün tek sorumluluğu, görüş ve model arasında aracılık eden sözleşme olmaktır. Görünüm yalnızca ekrandan sorumlu olmalı, model sadece iş mantığından sorumlu olmalıdır. Bu iki sorumluluğu kapatmak denetçilerin sorumluluğundadır.

Her şey yolunda ve iyi ama biraz akademiden uzak durmak; MVC'deki bir kontrolör genellikle birçok küçük eylem yönteminden oluşur. Bu eylemler genellikle bir şeyin yapabileceği şeylere karşılık gelir. Ürün satıyorsam, muhtemelen bir ProductController'ım olacak. Bu denetleyicinin GetReviews, ShowSpecs, AddToCart vb gibi eylemleri olacaktır ...

Görünüm, kullanıcı arayüzünü görüntüleme SRP'sine sahiptir ve bu kullanıcı arayüzünün bir kısmı AddToCart yazan bir düğme içerir.

Denetleyici, sürece dahil olan tüm Görünümleri ve Modelleri bilen SRP'ye sahiptir.

Denetleyiciler AddToCart Action, bir ürün sepete eklendiğinde dahil edilmesi gereken herkesi tanımak için belirli bir SRP'ye sahiptir.

Ürün Modelinde ürün mantığını modelleme SRP'si ve ShoppingCart Modelinde öğelerin daha sonra çıkış için nasıl kaydedileceği modelleme SRP'si bulunur. Kullanıcı Modelinde, kullanıcılara sepetlerine bir şeyler ekleyen bir modelleme SRP'si verilir.

İşletmenizi gerçekleştirmek için modelleri yeniden kullanabilir ve kullanmalısınız ve bu modellerin kodunuzun bir noktasında birleştirilmesi gerekir. Kontrolör, kuplajın gerçekleştiği her bir benzersiz yolu kontrol eder.

Denetleyicilerin aslında tek bir sorumluluğu vardır: uygulama durumunu kullanıcının girdisine göre değiştirmek.

Bir denetleyici , modelin durumunu güncellemek için modele komutlar gönderebilir (örneğin, bir belgeyi düzenleme). Ayrıca görünümün modelin sunumunu değiştirmek için ilişkili görünüme komutlar gönderebilir (örneğin, bir belgeyi kaydırarak).

_{source: wikipedia}

Bunun yerine Rails tarzı "denetleyicileri" (etkin kayıt örnekleri ve aptal şablonlar hokkabazlık) varsa , o zaman elbette SRP kırıyor.

Daha sonra, Rails tarzı uygulamalar gerçekten MVC değildir.