HMVC kalıbı nedir?

Kohana'nın belgelerini okurken, 3.0 sürümündeki temel farkın, sürüm 2.x'in yaptığı gibi MVC yerine HMVC modelini takip etmesi olduğunu öğrendim. Kohana'nın belgelerinde bununla ilgili sayfa ve wikipedia'daki sayfa bana gerçekten net bir fikir vermedi.

Öyleyse soru: HMVC modeli nedir ve MVC'den nasıl farklıdır?

Sam de Freyssinet (Kohana geliştiricilerinden biri) , HMVC , ne olduğu ve nasıl kullanılabileceği hakkında oldukça derin bir makale yazdı .

Bağlantı öldü: Yeni Bağlantı - https://web.archive.org/web/20160214073806/http://techportal.inviqa.com/2010/02/22/scaling-web-applications-with-hmvc/

Şu anda Alloy adlı kendi PHP 5.3 HMVC çerçevemi geliştirme sürecindeyim . HMVC'ye yoğun bir şekilde yatırım yaptığım ve satıldığım için, farklı bir bakış açısı ve belki de HMVC'nin neden kullanılması gerektiği ve sağladığı faydalar hakkında daha iyi bir açıklama sunabileceğimi düşündüm.

Bir HMVC mimarisi kullanmanın en büyük pratik yararı, içerik yapılarının "parçacıklı hale getirilmesidir". Bir örnek, yorumlar, derecelendirmeler, Twitter veya blog RSS beslemesi görüntüleri veya bir e-ticaret web sitesi için alışveriş sepeti içeriklerinin görüntülenmesi olabilir. Esasen, ana HTTP isteğinin bağlamına bağlı olarak, birden çok sayfada ve hatta muhtemelen farklı yerlerde görüntülenmesi gereken bir içerik parçasıdır.

Geleneksel MVC çerçeveleri genellikle bu tür içerik yapıları için doğrudan bir cevap sağlamaz, bu nedenle insanlar genellikle mizanpajları çoğaltıp değiştirir, özel yardımcılar kullanır, kendi pencere öğesi yapılarını veya kitaplık dosyalarını oluşturur veya istenen ana bilgisayardan ilgisiz verileri çeker. Görünüme geçmek ve kısmi olarak oluşturmak için denetleyici Bunların hiçbiri özellikle iyi seçenekler değildir, çünkü belirli bir içerik parçasını oluşturma veya gerekli verileri yükleme sorumluluğu birden çok alana sızmaya ve kullanıldığı yerlerde çoğaltılmasına neden olur.

HMVC veya özellikle bu sorumlulukları yerine getirmek için bir Denetleyiciye alt talepleri gönderme yeteneği bariz bir çözümdür. Ne yaptığınızı düşünürseniz, Kontrolör yapısına tam olarak uyar. Yorumlarla ilgili bazı verileri yüklemeniz ve bunları HTML formatında görüntülemeniz gerekir. Bu nedenle, yorum Denetleyicisine bazı parametrelerle bir istek gönderirsiniz, Model ile etkileşime girer, bir Görünüm seçer ve Görünüm içeriği görüntüler. Tek fark, yorumların, tamamen ayrı bir tam yorumlar sayfası yerine kullanıcının görüntülediği blog makalesinin altında satır içinde görüntülenmesini istemenizdir (ancak bir HMVC yaklaşımıyla, aynı denetleyiciyle hem dahili hem de harici isteklere hizmet verebilirsiniz ve "kill bir taşla iki kuş "dediği gibi. Bu bağlamda, HMVC, daha fazla kod modülerliği, yeniden kullanılabilirlik ve endişelerin daha iyi ayrılması için çabalamanın gerçekten doğal bir yan ürünüdür. BU, HMVC'nin satış noktasıdır.

Süre Yani Sam de Freyssinet en TechPortal makale HMVC ile ölçekleme üzerinde düşünmek ilginçtir, bu kadar değil nerede HMVC çerçeveler ondan gerçek, pratik, gün-gün avantajlar elde edecek kullanan insanların% 90 +.

HMVC, sevkıyat için "bileşen tabanlı" yaklaşımla yakından ilgilidir. Temel olarak, bir denetleyiciye delege eden tek bir dağıtıcıya sahip olmak yerine, her denetleyici kendi başına bir dağıtıcı görevi görebilir. Bu size bir kontrolörler hiyerarşisi verir. Tasarım daha esnektir ve kodun daha iyi kapsüllenmesine neden olur, ancak daha yüksek bir soyutlama pahasına. Konstrukt bu modele göre tasarlanmıştır.

Ayrıca şu yanıta bakın: /programming/115629/simplest-php-routing-framework/120411#120411

Kohana'da, en azından, bir HMVC isteği, "dahili olarak" hizmet verilen bir HTTP isteğidir: ağ üzerinden yayınlanmak yerine, çerçevenin kendisi tarafından yönlendirilir, gönderilir ve işlenir. "HMVC" ve "MVC" isimlerinin benzerliği, gerçekte var olmayan terimler arasında temelde yatan bir bağlantı olduğunu göstermesi açısından kafa karıştırıcıdır: biri diğerinin küçük bir varyantı veya modifikasyonu değildir, tamamen farklı şeylerdir. (HMVC, istemci tarafı HTTP isteği olmadan Ajax olarak da tanımlanır.) Kohana'nın vurgusu ve "HMVC" desteği, çerçevenin HTTP tabanlı hizmet odaklı mimari için güçlü bir desteğe sahip olduğu anlamına gelir.

Bu mimari modelin avantajı, aynı "arama kuralı" dahili ve harici istekler için kullanıldığından, "dahili" hizmet taleplerini "harici" isteklere dönüştürmenin ya da tam tersi ihtiyaç ortaya çıktıkça önemsiz olmasıdır.

Bu mantıklı bir mimari model olsa da, ona kendi adını vermek gereksiz görünmektedir (Symfony2 aynı kavramı " alt talepleri " tanımlar ) ve aslında isim yanlış bir isim gibi görünmektedir: taleplerin bir hiyerarşi (her zorunlu programın standart çağrı grafiğinden başka); örneğin istekler kolaylıkla özyinelemeli olabilir.

[ Güncelleme Nisan 2011, Mart 2012: Yorumlara yanıt olarak genişletildi.]

HMVC, Hiyerarşik Model Görüntüleme Denetleyicisidir.Normal MVC'de her GUI nesnesinin MVC'si vardır, ancak ana GUI nesnesi ile Alt GUI nesnesi arasında HMVC'nin aksine herhangi bir ilişki yoktur. HMVC'de her GUI nesnesinin kendi alt nesnelerine erişimi vardır ve her bir alt nesne kendi üst nesnesine erişebilir.

Yani her görünümde ebeveyn görünümüne erişebileceği bir ebeveyn görünümü vardır. Çünkü her denetleyicide, olayı üst denetleyiciye iletebileceği bir üst denetleyici vardır (Olay kapsamı içinde değilse.)

Ayrıntılı açıklama için lütfen buraya tıklayın

Yeni bağlantı bu adres