MVCS - Model Görünümü Denetleyici Mağazası


35

Geçenlerde iOS Development'ı öğrenmeye başladım ve bu amaçla iOS Programlama: The Big Nerd Ranch Guide adlı kitabı okudum . Yazarlar MVCS - Model-View-Controller-Store tasarım modelini açıklar , temel fikir, birçok uygulamanın, denetleyicideki istek mantığını kontrol altında tutmak yerine, birden fazla harici veri kaynağını kullanması nedeniyle yazarların yerine çok karışık olabileceğidir. tüm istek mantığının denetleyiciden ve ayrı bir nesneye taşınmasını önerir.

Kısacası kitabı alıntılamak

Model-View-Controller-Store istek mantığını ayrı bir nesneye yerleştirir ve biz bu nesneye bir mağaza deriz (Şekil 28.4). Bir mağaza nesnesi kullanmak gereksiz kodu en aza indirir ve verileri alan ve kaydeden kodu basitleştirir. En önemlisi, harici bir kaynakla başa çıkma mantığını net ve odaklanmış bir amaç ile düzenli bir sınıfa taşır. Bu, kodun anlaşılmasını kolaylaştırır; bu da ekibinizdeki diğer programcılarla paylaşmanın yanı sıra bakımı ve hata ayıklamasını kolaylaştırır.

Ve

Eşzamansız depolarla ilgili en güzel şey, bir nesnenin bir talebi işlemek için çok fazla çaba sarf etmesine rağmen, isteğin akışının ve yanıtının denetleyicide tek bir yerde bulunmasıdır. Bu bize okunması kolay ve değiştirmesi kolay kodun avantajını sağlar.

Bu model hakkında daha fazla bilgi edinmek ve başkalarının bu konuda ne söyleyebileceğini görmek istedim, ancak çevrimiçi arama yaparken bulabildiğim tek referans aynı kitaptı (belki de başka bir isim tarafından bilinen model?).

Bana göre yazarın mantığı mantıklı gözüküyor ve normal MVC modelinin mantıklı bir uzantısı gibi görünüyor, ama belki de pratikte MVC modeliyle pek fazla deneyimim olmadığı için (ideo gelişimine girişimin dışında) backbone.js ile kullanılan MVV tür (yani, MVC düşünürseniz )).

Belki de daha fazla deneyime sahip birisinin, eksik olduğum MVCS modeliyle ilgili herhangi bir açık kusur / sorun olup olmadığına ışık tutabileceğini umuyordum .


2
ActionScript'teki RobotLeg'ler, MVCS'deki "S" yi servis anlamına gelir. Fakat esasen aynı şekilde kullanılır. Yani bunun en az bir örneği var.
Amy Blankenship,

1
MVC'de Mağaza genellikle Modelin bir parçasıdır. Buna DAO kısmı deniyor.
Florian Margaine

@FlorianMargaine, Denetleyicinin aksine kullanıyor (bu kitapta ima edildiği görülüyor ("MVC istek mantığında denetleyici nesnelerinin sorumluluğundadır" yazıyor). ?
Jack

Yanıtlar:


18

"Mağaza", MVCS tasarım desenleri durumunda, depolama mantığına yaslanma eğilimindedir. İOS durumunda, bu genellikle bir Çekirdek Veri uygulamasıdır. Xcode'da bir Çekirdek Veri destekli şablon oluşturursanız, bu tasarım modelinin "Mağaza" özelliğini AppDelegate sınıfında saklanmış olarak görürsünüz.

Bunu bir sonraki seviyeye çıkarmak için, genellikle Çekirdek Veri yığınını ayarlamayı ele alan ve yığınla ilgili tüm alım / kaydetme ile ilgilenen bir singleton yönetici sınıfı oluşturacağım. Bahsettiğiniz teklifin dediği gibi, bu, yalnızca bu yöntemleri çağırmayı değil, gerektiğinde farklı görünüm denetleyicilerinde aramaları her yere kaydetme / getirme yerine, gerektiğinde ayarlama yapmayı çok kolaylaştırır.

“Mağaza” paradigması, Çekirdek Veriler ile sınırlı değildir. Mağazanız sadece bir web servisi olabilir. Muhtemelen Facebook, Twitter, Yelp veya başka bir REST tabanlı API ile etkileşime giren bir sınıfınız vardır. Bu tür sınıfların da Yönetici olarak adlandırıldığını buldum (ve benzer şekilde trendi takip ettim). Kelimenin tam anlamıyla bütün iç detaylarını çok iyi yönetiyorlar, böylece diğer sınıflarınız tam olarak ihtiyaç duyduklarını koyabiliyorlar.

Bu tasarım modelinde belirgin kusurlar veya sorunlar olduğu sürece ... Herhangi bir tasarım modelinde olduğu gibi, göze çarpan sorun, projenizi paradigma ile uyumlu olacak şekilde ayarlamanızı sağlamaktır. Özellikle sizin için yeni olan bir tasarım deseni ile bu bazen en zor kısım olabilir. "Mağaza" mantığınızı kendi sınıfına bölmenin yararı, kodların korunabilirliğini çok daha kolay hale getirmesidir.


İçgörü için teşekkürler, bu benim çekmeye başladığım yaklaşıma benziyor, çünkü çekirdek veri yığını ve bir Web API'si ile ilgilenen bir singleton yönetici sınıfım var.
Jack

Merhaba @jimstone, Mağaza mantığı ile ilgili biraz kafam karıştı. Lütfen yardım edebilir misin? Farz edelim ki, her biri için, biri ağ ve diğer nesnelerin önbelleğe alınmasını koruyan 2 sınıfa (Çekirdek veri vb.) Sahip 5 modelim olduğunu varsayalım. Şimdi, ağ oluşturma + önbellek işlevi çağrıları içeren işlevi çağıran her model için ayrı bir Mağaza sınıfına veya tüm ağ oluşturma + önbellek işlevini her model için çağıran tek bir Mağaza sınıfına sahip olmam gerekir, böylece denetleyici her zaman veri için tek bir dosyaya erişir.
meteorlar

18

Bu bağlamda 'Mağaza' bir Havuz veya Hizmete çok benziyor . Bu durumda, bu son derece yaygın bir kalıptır. Kusurlar / problemler uygulamanıza ve problem alanına göre değişecektir.

Genel bir düzeyde, kitap uygulamanızın bir parçası olabilecek ya da olmayabilir bir veri kümesini işleyen bir veri toplama mantığı düzeyini ve bir iş mantığı düzeyini temsil etmek için 'Mağaza'yı kullanıyor gibi görünüyor.

Örneğin, twitter api'yi bir 'Mağaza' içine sarmak, bu mantığı bölümlendirmenin güzel bir yoludur.

Daha fazla düşünmek üzerine
MVC'nin bu tanımını kullanarak (ki bence oldukça dikkat çekicidir), 'Mağaza' gerçekten modelin bir alt kümesidir. MVC'nin bir uzantısı olup olmadığı veya bir veri alma modeli olup olmadığı arasındaki ayrım çok faydalı değildir. Sonunda aynı koda benziyorlar.

Sonuç olarak, önerdikleri tavsiyelere uyarak iyi olacağınızı düşünüyorum (genel olarak sağlam görünüyor).


1
Sağladığınız linkleri okumak Okuma, burada MVC düzeninin bir uzantısı olarak kullanılması dışında, kulağa benzer geliyor.
Jack

5
+1, depo deseni için yeni bir ad bulmuş gibi ses çıkarıyor (depo bir tür hizmettir).
MattDavey
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.