MVC ve RESTful API hizmeti

MVC oldukça basittir. Bir Model, bir Denetleyici ve bir Görünüm var. Bir web sitesi oluşturduğumuzda, hepsi ' istemci sunucuya REST anahtar kelime isteği gönderir -> sunucu istenen URL'yi denetleyici eylemiyle eşleştirir -> sonra veri toplama / işleme için modelleri çağıran sonucu alır -> ve sonucu istemciye HTML sayfası (görünüm) olarak döndürür '.

Saf bir RESTful API web hizmetinden bahsedersek ne olur? Daha sonra ' istemci sunucuya REST anahtar kelime isteği gönderir -> sunucu istenen URL'yi denetleyici eylemiyle eşleştirir -> gibi bir akış olur ve bu da veriyi toplama / işleme için modelleri çağırır, sonucu alır -> ve döndürür sonuç JSON'da istemciye geri döner . Öncekiyle aynı, ancak 'görünüm' yok ... ya da daha doğrusu, oluşturulan JSON 'görünüm' olarak düşünülebilir. Bir bakıma, sadece MVC'nin MC kısmını kullanıyoruz. Bu nasıl yapılmalı? Yoksa MVC yerine yalnızca API hizmeti için daha uygun başka kalıplar var mı?

MVC, Smalltalk dünyasından nesne yönelimli sistemlerin UI'lere nasıl sahip olabileceğiyle ilgili bir paradigmadır.

İlk web çerçeveleri genel fikri (iş mantığını ayırma, mantığı kontrol etme ve mantığı görüntüleme) aldı ve prensibi web uygulamasını nasıl yapılandırdıklarına uyguladı. Bundan önce, Tanrı'nın etki alanı nesneleri içinde HTML nesil kodunda korkunç bir karışıklığa veya HTML şablonlarının içinde iş mantığına sahip olması nadir değildi (PHP'yi çok erken düşünün)

Mesele şu ki, Smalltalk dünyasından orijinal MVC, çoğu web çerçevesindeki MVC'nin gerçekte ne olmadığıdır. HTML çıktısı, Smalltalk'ın bir kullanıcı arayüzü ekranını anlaması anlamında gerçekten bir "görünüm" değildir.

MVC'yi doğru bir şekilde takip edip etmediğinize çok fazla asılmamak için ilk neden budur. Neredeyse hiçbir şey yok. HTML şablonlarımız iş mantığıyla dolu olmasaydı , katı bir bölüm olarak daha az alın ve Hey'in bir kılavuzu daha iyi olmazdı.

İkinci olarak MVC, sunucu tarafı kodunu yapılandırmanın bir yoludur. REST / HTTP ile gerçekten ilgisi yok. REST, istemcilerin ve sunucuların nasıl iletişim kurduğuyla ilgilidir. Sunucunun istemciye gönderdiği temsilin, şablonlama motoruyla veya denetleyicide bir çağrı olan bir JSON nesnesiyle oluşturulması çok zaman alan bir HTML şablonunda olması önemli değildir.

Sunucunuzun iyi bir "görünüm" katmanına ihtiyacı olduğunu düşünmüyorsanız. Tüm denetleyici, bir nesne üzerinde bir JSON ayrıştırma çağrısı çağırıp bu verileri döndürse bile, iş mantığınızı (yani modelinizi) belirli bir HTTP isteğini işleyen denetleyicilerden ayırmaya devam edersiniz.

Görünüm, uygulamanızın bir kullanıcısı / istemcisi tarafından yorumlanabilecek bilgilerin görüntülenmesinden sorumlu bir katmandır (kullanıcının gerçek kişi olması gerektiği anlamına gelmez). Bir görünüm katmanı için JSON tamamen geçerli bir formattır, bilgisayarlar bunu anlar.

Görünüm katmanı, bir kullanıcı tarafından uygulamanızdaki modelleri etkilemek için kullanılabilecek bilgiler yayınladığı sürece, görünümün nasıl göründüğü önemli değildir, yine de bir görünümdür, kullanıcı ile sistem arasında ara katman görevi gören bir katmandır. .

MVC oldukça basittir.

Martin Fowler, belki de buna katılmıyordu :

Farklı yerlerde MVC hakkında okuma yapan farklı insanlar ondan farklı fikirler alır ve bunları 'MVC' olarak tanımlar.

Hareketli...

Bir web sitesi oluşturduğumuzda, hepsi 'istemci sunucuya REST anahtar kelime isteği gönderir -> sunucu istenen URL'yi denetleyici eylemiyle eşleştirir -> sonra veri toplama / işleme için modelleri çağıran sonucu alır -> ve sonucu istemciye HTML sayfası (görünüm) olarak döndürür '.

Tamam, bu biraz karışıklık

MVC, ne olursa olsun, kullanıcı arayüzlerini uygulamak için bir fikir topluluğudur.

REST, büyük ölçekli uygulamalar oluşturmak için mimari kısıtlamaların bir koleksiyonudur.

Burada bahsettiğiniz şey olan web, aynı kısıtlamaların çoğunu kullanarak oluşturulmuş dev bir belge yönetimi uygulamasıdır.

İkisi arasında gördüğünüz benzerlikler yanlış seçim (yüzeysel).

RESTafarianlar HATEOAS , "uygulama durumunun motoru olarak hipermetin" hakkında ortak bir anlayışa sahiptir ve bu durum sizin başınızdan çınlayan alarmlar göndermelidir - bir görünüm neden devletin motoru olur ? Önermeyi sorgularsak ve ek kanıt ararsak, iki garip şeyi de fark edebiliriz.

İlk olarak, HTML'yi diskten yükleyerek HTTP sunucusunu denklemin tamamen dışına çıkarabiliriz. Tarayıcı bununla mükemmel bir şekilde ilgilenir ve temel url'deki değişiklikten kaynaklanabilecek bazı küçük davranış çeşitlerini hariç tutar. Görünümler genellikle model ve denetleyiciden tamamen ayrıldıklarında çalışmaya devam etmez.

İkincisi, modern bir tarayıcıyı dikkatlice gözlemlersek, HTML'nin birden çok görünümü olduğunu fark edeceğiz. Bir görünümün birden çok görünümü gerçekten garip bir fikir gibi görünüyor, ancak kullanıcı sunumlarına yanıt veren bir grup metin işaretlemesiyle ana sunumun yeterince olduğundan emin olun ve sonra ham HTML'yi gösteren ve ayrıca yanıt veren bu "Kaynak Görünümü" kullanıcı hareketleri. Bütün yol boyunca kaplumbağalar!

Bilmecenin cevabı, elbette, HTML'nin görünüm olmadığıdır. Tarayıcıdaki widget'ların koleksiyonu görünümdür ve HTML okunarak başlatılan Belge Nesne Modeli ile iletişim halindedir .

Başka bir deyişle, HTML, Roy T. Fielding'in vaat ettiği gibi bir devlet temsilidir .

Saf RESTful API web hizmetinden bahsediyorsak ...? Öncekiyle aynı, ancak 'görünüm' yok

Daha doğru, öncekiyle aynı: görünüm yok. JSON, tıpkı HTML gibi, süreç sınırlarını aşmaya uygun bir durumun temsilidir.

"DTO" ya da "Message" deyin ve çıkarımların sizi yanlış yola sokma ihtimali daha düşük olacaktır.

Bu nasıl yapılmalı?

JSON'u görünüm olarak geçirmek veya görünümü oluşturmak için görünüm modeli olarak kullanmak kalıbı ihlal etmez.

Üzerinde çalıştığım uygulamada aynı mimariyi kullanıyorum ve çok iyi çalışıyor. Bazı güzel JS çerçevesiyle birlikte gerçekten duyarlı tasarımlar oluşturabilirsiniz.

Yoksa MVC yerine yalnızca API hizmeti için daha uygun başka kalıplar var mı?

Dürüst olmak gerekirse, hiçbir fikrim yok. Ama bence bir API MVC kullanıp olsun o önemli olmadığını. Uygun bulduğunuz her şeyi kullanın. Web hizmetleri hakkında konuşurken, güvenlik, tutarlılık, kullanılabilirlik vb. Gibi (doğrudan MVC ile ilgili olmayan) dikkate alınması gereken çok daha önemli yönler vardır.