MVC'de bir API isteğini nereye koymalıyım?

MVC deseni kullanarak bir web uygulaması yapıyorum. Bu tür bir mimarinin ardından veritabanı ile etkileşimde kullanılan tüm yöntemlerin modelde uygulandığını görebiliriz .

Ancak başkalarının maruz bıraktığı bir hizmeti web üzerinden aramak zorunda kalırsam ne olur? Örneğin, sayfamın tüm takipçisini alabilmek için Facebook API’ya erişmek istiyorum, öyleyse bu yöntemleri nereye koydum?

Açıkçası, görüş iyi bir fikir değil çünkü bu modül sunuma adanmış, kontrolör veri almak için kullanılmamalı, ancak model genellikle sadece veritabanı ile etkileşime adanmıştır.

Peki, bu konuda bana biraz ipucu verebilir misiniz? Ve lütfen, MVC mimarisiyle ilgili bazı hatalar yaptığımı söyleyebilir misiniz?

Model veri tabanı ile etkileşimi ile sınırlı değildir, model veriyi almak ve değiştirmekle sorumludur.

Bu nedenle, bakış açınıza ve kontrol biriminize göre, veriler bir veritabanından veya bir web servisinden geliyorsa veya hatta tamamen rastlantısalsa bile, hiçbir fark yaratmamalı, bu nedenle bunu modelde yapmalısınız.

MVC, yalnızca farklı temsil katmanlarını ayıran bir sunum düzenidir.

Bu, modelin tek tip bir spagetti kodu karmaşası olması gerektiği anlamına gelmez. Modeliniz kendisi de katmanlı olabilir, ancak kontrolör verilerin nereden geldiğini bilmemelidir.

Modelinizdeki genel bir yöntem, denetleyiciniz tarafından çağrılabilen şu şekilde (Sözde kod) yapılandırılabilir:

public MyDataClass getData(int id) {
    WebServiceData wsData = WebService->getData(id);
    DatabaseData dbData = ORM->getData(id);
    return new MyDataClass(wsData, dbData);
}

WebServiceve ORMbağımlılık enjeksiyonuyla sahte olarak değiştirilebilecek olan arayüzlerin örnekleri olması gerekebilir, ancak kontrolörleriniz ve görüşleriniz test amacıyla değişmek zorunda değildir.

M, V ve C'nin ne olduğu konusunda ortak (kasıtlı?) Bir yanlış anlaşılma var. Aldıkları roller hakkında değil , onlar ne .

MVC'nin orijinal masaüstü GUI tanımında modüllerdi . Tipik olarak bir uygulamanın birçoğu vardı, bazen üçüzler halinde çalışıyordu, bazen birkaç kontrolcünün karıştırıp eşleştirebileceği çeşitli görüşlere ve modellere sahipti.

Web çerçevelerinde OTOH, her birinin yalnızca bir tanesi olduğu katmanlar olarak görülmeye meyillidir ve çoğunlukla bazı sübstrasyonlu soyutlama seviyelerini kapsar: "model katmanı veri tabanını çıkarır", "görünüm katmanı sunum", "denetleyici" katman kullanıcı girdisini işler ".

Dolayısıyla, zaten veritabanınızla etkileşime adanmış bir modeliniz olduğunu ve şimdi kaynak API'nızla ilgilenmek için başka bir model oluşturmanız gerektiğini söyleyebilirim . Bunları mümkün olduğunca benzer yaparsanız, denetleyici ve görünüm kodunun çoğu her iki modelde de sorunsuz çalışabilir.

MVC'nin tartışılmasındaki zorlukların bir kısmı, farklı grupların farklı şeyler ifade etmek için kooperasyon yapmalarıdır. Bir Rails uygulamasında kullanılan MVC uygulaması, bir Swing uygulaması yazan bir kişi için neredeyse tanınmayacaktı. MVC'nin hala iyi tanımlanmış bir şey olduğu ölçüde, bir dizi yol gösterici ilkeden daha fazlasıdır (çekirdek uygulamayı görsel temsilinden ayırmak, ikisinin birlikte döşenmesini sağlamak için esnek mekanizmalar sağlamak). yolları.

Gerçekten de, farklı MVC türetilmiş tasarımlara farklı isimler verme eğilimi vardır ( bu konunun biraz tartışılması için bu makaleye bakınız ), hatta kesin isimlerden vazgeçme eğilimi vardır - örneğin, AngularJS kendini bir Model-View-Whatever olarak tanımlamaktadır. çerçeve.

Bu nedenle, hangi "MVC" versiyonunun üzerinde çalıştığınızı bilmeden cevap vermek zor. Bununla birlikte, bir API talebi tipik olarak çoğu uygulamada tamamen modelin içinde yer alacak olan çekirdek uygulamanın (farklı bir görsel sunum kullanmaya karar verirseniz değişmemesi gereken kısım) bir parçası olacaktır.

İşte , model şöyle açıklanmaktadır:

Bir model kontrol cihazına alınan ve görünümde görüntülenen verileri saklar. Verilerde herhangi bir değişiklik olduğunda, denetleyici tarafından güncellenir.

Denetleyicinin ya servisi arama mantığını içerdiğini ya da ayrı bir Servicenesneyi çağırdığını söyleyebilirim . Servis ayrıysa, daha kolay bir şekilde testler oluşturabilirsiniz, örneğin, bir şebeke üzerinden bir servisle bağlantı TestServicekurulamazsa , bazıları Serviceyerel olarak cevap verebilir .

Ayrıca Kontrolörün servisi aradığını öne süren bu cevaba da bakın.

Modeliniz hiçbir zaman gerçek bir kod içermemeli ve denetleyici tarafından manipüle edilen ve görünüm tarafından görüntülenen içeriği yönetmek için kullanılan bir mesaj veya yapı olarak görülmelidir.

Değişiklik isteyen herhangi bir API, veritabanı, hizmet vb. İle iletişim kurmaktan ve modelde gerekli güncellemeleri yönetmekten denetleyiciniz sorumlu olmalıdır.

MVC modelinin tüm gücü, mantığı (denetleyiciyi) görünüm ve durumdan (model) ayırmasıdır. Bunu yaparken, yalnızca kontrol cihazındaki kodun, görünüm ve modelde değişiklik yapmasına izin verilmediğinden yan etkiler yaratabileceğinin garantisi vardır.

Ayrıca, bir model çeşitli denetleyiciler ve görünümler arasında paylaşılabildiğinden, kodun daha iyi kullanılmasını sağlar.

Burada yoldan çıkmış olabilir, ancak WebApps hakkında hissediyorum ve birçok durumda [karmaşık] uzak API'lerle çalışmam böyle:

Bunu model yerine (yani veri azaltma işlevlerinin yığını) bir sınıf (yani bir veri azaltma yöntemleri kütüphanesi) yapardım. Görünüşe göre daha şeffaf, daha mantıksal / şema agnostik gibi gözüküyor ve onu kullanmak istediğiniz her seferde bir model / kontrolör çağırmadan herhangi bir yerde kullanmadan kullanabilirsiniz. Mantık hala ayrılmıştır, veri noktası hala esnektir ve uç noktayı dolaylı olarak yoklamak için istemciAJAX-> appJSON-> appLIB-> remoteAPI-> remoteJSON gibi istifleme gibi garip durumlarda birlikte çalışabilirlik için daha açık görünmektedir.