MVC'nin olumsuzlukları nelerdir? [kapalı]

Yıllar önce kodumu düzenlemeye başladığımdan beri MVC / MV * kullanıyorum. O kadar uzun süredir kullanıyorum ki kodumu yapılandırmanın başka bir yolunu bile düşünemiyorum ve stajyer olduktan sonra yaptığım her iş MVC tabanlıydı.

Benim sorum şu, MVC'nin olumsuzlukları neler? Hangi durumlarda MVC bir proje için kötü bir seçim olacaktır ve (daha fazla) doğru seçim ne olacaktır? MVC alternatiflerine baktığımda, hemen hemen her sonuç sadece farklı MVC tipleridir.

Kapsamın daraltılmaması için kapsamın daraltılması, diyelim ki web uygulamaları için. Farklı projeler için arka uç ve ön uç üzerinde çalışıyorum, bu yüzden sadece ön uç veya arka uç diyemem.

Her zaman hatırlamalısınız - MVC UI ile ilgili bir kalıptır. Karmaşık bir uygulama inşa ediyorsanız, UI ile ilgili olmayan her şey, MVC üçlüsü dışında diğer sınıflara, alt sistemlere veya katmanlara uygulanmalıdır.

Bu benim en büyük hataydı. Bu basit kuralı anlamak için uzun zaman harcadım:

• Bir MVC desenini tüm uygulamaya yaymayın,
• Yalnızca kullanıcı arayüzü ile ilgili şeylerle sınırlandırın.

Her zaman yazdığınız kodun mantıksal olarak doğru yerde olup olmadığını kontrol edin, yani mantıksal olarak koyduğunuz sınıfın sorumluluk alanına girer.

MVC alternatifleri olarak adlandırdığınız tüm modeller (yani Model-View-Presenter, Model-View-ViewModel) genel MVC konseptini uygulamanın bir yoludur.

Bence iki tip MVC var - saf ve saf (daha iyi bir kelime bulunmadığı için :)

Saf MVC, küçük konuşmaya tanıtılan şeydir:

Bu kişisel bilgi işlem / masaüstü uygulamaları için yapıldı. Gördüğünüz gibi, model üzerinde yapılan herhangi bir güncelleme / değişiklik hakkında görüş bildirir. (Saf olmayan) MVC ile öyle değil.

Web uygulamaları için tanıtılan diğer (saf olmayan) MVC, yukarıdaki klasik MVC yerine bir PAC ( Sunum-soyutlama-kontrol ) modelinden daha fazladır . Bu daha çok kod organizasyonu ve endişelerin ayrılmasıdır:

• Model : Saklanan veriler için soyutlama
• Kontrol : Genellikle, iş mantığı katmanı olarak bilinenler ve HTTP isteklerini ilgili iş mantığına yönlendirmekle sorumlu uygulamanın bir parçası (aka kontrolör)
• Görünüm : Çoğunlukla, verileri modelden biçimlendiren şablonları görüntüleyin ve istemciye geri gönderin. Model ASLA güncellemeleri görünüme göndermez. Görünüm, bir modelden gelen güncelleştirmeler için 'abone' de olmaz. Birleşiyor kabus olurdu. Bu nedenle, gerçek MVC'den daha PAC gibi.

Şimdi, bir web uygulamasının genellikle nasıl yapılandırıldığı:

1. Ön uç : Müşteriler üzerinde MVC'yi Backbone.js vb. Gibi çerçeveleri kullanan, Bu, esasen 'gerçek' MVC formudur.
2. Arka uç : Yine, kod organizasyonu ve endişelerin ayrılması için MVC / PAC'iniz var
3. Genel web uygulaması (bir bütün olarak web uygulaması için): Yalnızca JSON verilerini döndüren RESTful arka uca sahipseniz, arka ucunuzun tamamı , Görünüm ve Denetleyicinin özünde bulunduğu ön uç istemci uygulaması için bir model olarak algılanabilir .

Peki MVC'nin bazı dezavantajları nelerdir? Pekala, model zamanın testine dayanıyordu, bu yüzden biraz 'karmaşık' olmasından başka bir şey yok. MVC'nin bileşik bir kalıp olduğunu görüyorsunuz - strateji / gözlemci kalıbını uygular ve hepsi de yüksek seviyeli bir kalıp oluşturacak şekilde düzenlenmiştir.

Her yerde mi kullanmalısın? Belki de değil. Son derece karmaşık web uygulamaları belki birden çok katmana ayrılabilir! Yalnızca View / Business Logic / Data katmanları ile kurtulmanız mümkün olmayabilir. Genel çerçeve / organizasyon hala MVC-ish olabilir, ancak yalnızca makroskopik düzeyde olabilir.

İşte sadece MVC'nin kendi başına kötü bir seçim yapabileceği bir örnek : Hava trafik kontrol sistemi veya büyük bir banka için bir kredi / ipotek işleme uygulaması tasarlamayı deneyin - sadece MVC tek başına kötü bir seçim olacaktır. Kaçınılmaz olarak, bireysel katmanlar içinde MVC içeren çok katmanlı bir mimarinin yanı sıra kod tabanını daha iyi organize etmek için büyük olasılıkla çalışan bir MVC / PAC tasarımıyla birlikte Olay otobüsleri / mesaj kuyruklarına sahip olacaksınız.

Bir çok insanın tasarım desenleriyle yaptığı hata, bir yerde güzel bir şekilde çalıştığını görmek ve daha sonra her yere uygulamaya çalışmaktır.

Bir süre bir yerde çalıştıysanız, o sırada hangi teknolojilerin / tasarım kalıplarının / uygulamalarının moda olduğunu görmek için neredeyse bir kod parçası çıkarabilirsiniz, örneğin, singleton / bağımlılık enjeksiyonu / TDD vb.

Nerede kullanmayacağınıza gelince. Peki, MVC üçlüsünün bir elementi geçerli değil. Konsol uygulamaları bir arabirim uygulayamayabilir. Yardımcı programların bir modeli olmayabilir. Ve tartışmalı olarak, ne bir modeliniz ne de bir görünümünüz varsa, kontrolör gerektirmez.

Sorun nadiren kavramla ilgilidir - uygulama ile daha fazla. Paradigma ne kadar iyi olursa olsun, eldeki sorun için uygun olup olmadığını görmek için zaman ayırın.

MVC, geliştirme platformunuza entegre olmayan herhangi bir paradigma gibi, karmaşıklığı arttırır. Bunun dezavantajı, ayrı olmamaları gereken ayrılan sınıfları sarar ve ne kadar sıkı bağlı olduklarının netliğini azaltır. (Veya, önemsiz projeler için bile kodunuzu engeller.)

İlk problemin alternatifi bu kodu bağımsız alt projelere ayırmak; ikincisinin alternatifi, sınıfta veya dosya modelinde ayrılmış koddur.

MVC / MV * uygulama anlayışım, Her bir bölümün ayrı bir endişeyi ele alabilmesi için Programın / Kodların ayrı bölümlere / parçalara ayrılmasıyla ilgili Endişelerin Ayrılması (SoC) ilkesini izlemektir (Ref: http://en.wikipedia.org / wiki / Separation_of_concerns )

Endişeleri ayırmanın bir çok faydası vardır: biri diğerini etkilemeyecek ve geliştiriciler geri kalanı, vb. etkilemeden bir birim üzerinde çalışabilirler vb. vb. MVC SoC'yi izleyen tek kalıp değil, temelde OOP işleri birimlere ayırmak için harika bir konsept.

MVC / MV *, UI ile ilgili gelişmeyi ele alırken çok faydalıdır; bunun altında, altta daha fazla desen olabilir - fabrika, singleton, cephe vb. Büyük projelerin çoğu, farklı yönleri işleyen çok sayıda katmandan oluşur, ancak UI için bir zorunluluk olmayabilir. bazı durumlar. MVC'yi çok fazla görebilirsiniz - çünkü birçok projede UI öğesi vardır.

Bu nedenle, MVC'nin sakıncalarından bahsederken, gerçekten yaptığınız projelere bağlı - kullanıcı arayüzü var mı? Mükemmel ölçeklenebilirlik / genişletilebilirlik gerektiriyor mu? UI ve sistem arkasında birçok etkileşime sahip mi? Örneğin, basit bir bilgi web sayfası, gelecekte büyük bir etkileşimli sayfaya genişletmeyi planlamıyorsanız, MVC'yi hiç gerektirmez.

bu yüzden MVC'yi (veya daha genel - bir tasarım modelini) değerlendirmek için, ona bir bağlam verin ve karmaşıklık, ölçeklenebilirlik, test edilebilirlik, bakım, zaman kısıtlaması vb.