Ajax ile MVC görünümlerine karşı Web API ile Pure Front end JavaScript

Bu, günümüzde bir web uygulamasının nasıl bölüneceği konusunda insanların düşüncelerinin ne olduğu üzerine bir tartışma oldu.

Tüm görünümleri ve denetleyicileri ile bir MVC uygulaması oluşturmak için alışkınım. Normalde tam bir görünüm oluşturur ve hemen doldurmak istemediğim belirli alanlar olmadıkça ve daha sonra diğer alanları yüklemek için sunucuyu çağırmak için DOM sayfa yükleme olaylarını kullanmazsam, bunu tam sayfa isteğinde tarayıcıya geri gönderirim AJAX kullanarak.

Ayrıca, kısmi sayfa yenilemeye geldiğinde, sayfanın bölümlerini doldurmak için kullanabileceğim HTML parçasını döndürecek bir MVC eylem yöntemi çağırırdım. Bu, ilk sayfa yükünü yavaşlatmak istemediğim alanlar veya AJAX çağrılarıyla daha iyi donatılmış alanlar için olurdu. Örnek olarak tablo sayfalaması verilebilir. Bir sonraki sayfaya geçmek istiyorsanız, bir AJAX çağrısı tam sayfa yenilemesi kullanmak yerine bu bilgiyi alırsa bunu tercih ederim. Ancak AJAX çağrısı yine de bir HTML parçası döndürür.

Sorum şu. Saf bir ön uç arka plan yerine .net arka planından geldiğim için bu arka plan üzerine düşüncelerim var mı?

Birlikte çalıştığım akıllı bir ön uç geliştirici, MVC görünümlerinde az ya da çok hiçbir şey yapmayı tercih ediyor ve her şeyi ön uçta yapmayı tercih ediyor. Sayfayı dolduran web API çağrılarına kadar. Böylece, HTML döndüren bir MVC eylem yöntemini çağırmak yerine, standart bir nesneyi döndürmeyi ve sayfanın tüm öğelerini oluşturmak için javascript kullanmayı tercih eder.

Ön uç geliştirici yolu, istemci tarafı doğrulaması da dahil olmak üzere normalde MVC modeli doğrulamasıyla elde ettiğim tüm avantajların ortadan kalkacağı anlamına gelir. Ayrıca, güçlü bir şekilde yazılan html şablonları vb.Ile görünümler oluştururken elde ettiğim herhangi bir avantajın gitmiş olacağı anlamına gelir.

Bunun ön uç ve arka uç doğrulaması için aynı doğrulamayı yazmam gerektiği anlamına geldiğine inanıyorum. Javascript'in ayrıca DOM'un tüm farklı bölümlerini oluşturmak için birçok yönteme sahip olması gerekir. Örneğin, bir tabloya yeni bir satır eklerken, normalde satır oluşturmak için MVC kısmi görünümünü kullanır ve daha sonra bu tabloya enjekte AJAX çağrısının bir parçası olarak dönecekti. Saf bir ön uç yolu kullanarak, javascript api çağrısından satır için bir nesneyi (örneğin, bir ürün) alır ve daha sonra bu nesneden bir satır oluşturur. Tablo satırının her bir parçasını oluşturma.

Söz konusu web sitesi, yönetim, formlar, ürün arama vb. Gibi birçok farklı alana sahip olacaktır. Sanmıyorum bir web sitesi, tek sayfalık bir uygulama şeklinde tasarlanmalıdır.

Herkesin bu konudaki düşünceleri nelerdir?

Ön uç geliştiricileri ve arka uç geliştiricileri duymak ilgimi çekiyor.

Ayrıca, her yeni web uygulamasının bir SPA olması gerektiğinden biraz şüpheliyim, ancak müşteri tarafında deneyiminin büyük bir kısmıyla genel olarak% 100 satıldığım bir şey, ham elden hizmet odaklı bir mimarinin istemciye HTML yerine veri, sunucudan önceden oluşturulmuş sayfaları / görünümleri yükleyip, sayfa yüklendikten sonra verilerle çok sayıda dinamik öğe yapıp yapmadığınızı veya JavaScript ile hemen hemen her şeyi% 100 oluşturduğunuzda gitmenin yoludur.

Bunun bir istemci tarafı geliştiriciye tercih edilmesinin nedenleri, hiç kimsenin veritabanında HTML istememesinin nedenleriyle aynıdır. İstemci tarafındaki geliştiricinin, örneğin HTML verildiğinde bir tabloya başvurmak istediklerinde ne yapması gerekiyor? İstemcide tüm bunları işlemenin performans maliyeti, sizin için başka bir sunucu isteği yapmakla karşılaştırıldığında önemsizdir. Ayrıca, HTML oluşturma JS-arazisinde oldukça iyi kaplıdır. Verileri sıralamak ve yeni HTML tablo satırları oluşturmak, deneyimli bir istemci tarafı geliştirici için oldukça önemsiz bir çalışmadır.

Ve% 100 tuval veya tamamen farklı bir HTML yapısı olan uygulama widget'ları gibi egzotik bir şey yapması gerekebilecek başka bir cihaz için arka uç mimarisinin bir ön uca ne faydası var? Neden bir müşteri tarafı geliştirici görsel sunum yüklemeli veya tam bir sunum yapmak için arka uç geliştirici kapısını çalmalı?

Güçlü yazılan şablon doğrulama kaybıyla ilgili endişelerinize gelince, yetkili bir müşteri tarafı geliştiriciyle uğraşıyorsanız, daha fazla kömürden daha fazla .NET çerçevesi veya görsel stüdyo aracı bulamayacağınızı söylediğimde bana güvenin elmas-toz-ezici bir şekilde anal, iyi biçimlendirilmiş, geçerli HTML hakkında.

Tam yığın perspektiften hoşuma gidiyor çünkü iş veya uygulama mantığı için asla balık tutmam gerekmeyecek, bazı yutzlar şablon katmanına düşmeye karar verdi. Çoğu durumda, modern bilgisayarlara sahip modern tarayıcılarda kullanıcı için yük deneyimini geliştirirken, sunucularınızdan aldığı kullanıcı başına yükten bahsetmiyoruz.

Bence tüm sunum malzemelerinden tamamen izole ettiğinizde arka uç mimarisini düşünmek daha kolay. Artık verileri HTML'ye dönüştürmek için veri almıyorsunuz. Genel kullanımda kendisini diğer tarafta yapacaklarından daha fazla ilgilendiren, uygulamadan bağımsız bir veri yapısı oluşturmak için bir araya getiriyorsunuz. Veriler bir sürecin ikinci ve son basamağından ziyade bir son hedef olduğundan, işlerin nasıl ele alındığı konusunda daha fazla tutarlılığa yol açma eğilimindedir ve ilgisiz endişelerin kablolarını geçmesi için daha az fırsat vardır.

Benim son derece öznel 2 kuruş değer sunacak (ne için değer;)). Buna doğru ya da yanlış bir cevap yoktur ve puanlarınıza ek olarak birçok gerçek dünya düşüncesi vardır, örneğin:

• Evde ilgili deneyiminiz var mı? bir istemci tarafı tahrikli uygulama oluşturmak tamamen farklı bir beceri seti ile ağırlıklı olarak sunucu tahrikli bir uygulama çok farklıdır.
• Ne kadar sürmesini istiyorsunuz ve hangi tarayıcıları desteklemeniz gerekiyor? - istemcide ne kadar çok şey yaparsanız o kadar çok tarayıcı sorunuyla karşılaşırsınız; IE8 acı verici ve JavaScript performansı oldukça zayıf, ancak XP / IE kurulumlarını çalıştıran birçok işletme var.
• Kullanıcılarınız siteyi hangi cihazlarda görüntüleyecek? JavaScript ayrıştırma ve çalıştırma, Chrome'un son bir sürümünde hızlı olabilir - ancak eski bir mobil cihazda değil, özellikle içinde bir iş mantığı içeren büyük miktarda JavaScript değil
• İlk yük ne kadar önemlidir? Sunucu şablonu, istemci şablonundan daha hızlı

Bu liste hiçbir şekilde ayrıntılı değildir ve niyetim olmayan bir müşteri tarafı dayak gibi geliyor, ön uçta ağır bir vurgu yapan siteler yaptım.

Benim için gerçekten kullanıcı deneyimi ve API yeniden kullanılabilirliği söz konusu. Bunların her birini ele almak için.

Bir uygulama yapacak veya bir API sunacaksanız, bir .Net API projesi kullanmak çok mantıklıdır, bu daha sonra mantık, kontrol ve uygulama çapraz platformunu oluşturur. Bu senaryoda, tam bir istemci tarafı yaklaşımı uygun olabilir, API ayrı olarak muhafaza edilebilir ve sadece uygulamanıza bir arayüz sağlar. Mantık ve yeniden düzenleyiciyi rahatça değiştirebilir ve sadece arayüzü aynı tutmanız gerekir. Aynı ortam kodunu kullanarak farklı ortamlar için kolayca farklı uygulamalar yazabilirsiniz.

Saf bir ön uç çözümü (bence) için en güçlü argüman kullanıcı deneyimidir.

Saf bir JavaScript tarayıcı uygulaması (tüm olumsuz yönleri göz önüne alındığında) geleneksel bir web sitesinde kullanılabilirlik ve kullanıcı deneyimi üzerinde önemli bir gelişme sağlıyor mu?

Yerel uygulamalar gibi çalışan siteler oluştururken; Cevabın açık bir evet olduğunu iddia ediyorum. Bununla birlikte, çoğu site bu temiz kesim değildir, bu nedenle bireysel kullanıcı iş akışlarının oldukça dinamik bir arayüzden faydalanıp faydalanmadığı değerlendirilir.

Buna oldukça pragmatik bir bakış açısıyla bakıyorum, bu bir ya da mesele değil; JavaScript açıkça Sunucu teknolojileri ile birlikte mutlu bir şekilde oynayacak ve birini veya diğerini seçmek zorunda değilsiniz - her site tek sayfalık bir web uygulaması değildir - ancak ayrı ayrı sayfalarda Nakavt, omurga vb. gerekli gördüğü yerlerde geliştirin.

Ön uç ağır uygulamalarla aşk-nefret ilişkim var.

Bir yandan JavaScript yazmayı ve tarayıcıyı bir yürütme ortamı olarak seviyorum.

Öte yandan, her ikisi de motorda delikleri olan Formula 1 yarış arabası gibi hissediyor. Gerçekten buna bağlı: C # ve JavaScript arasında iş mantığının kopyalanmasını önleyebilir misiniz? Öyleyse, layık gördüğünüz görünümü oluşturmak için herhangi bir yöntemi kullanın. İş mantığını iki dilde çoğaltıyorsanız, yalnızca JavaScript yazmak isteyen ve büyük resmi tam olarak görmeyen bir kullanıcı arabirim geliştiriciniz olabilir.

Teknik farklılıklara gelince:

Kısmi oluşturma ve istemciye teslim etme:

• Uygulaması kolay ve hızlı
• Arka uç iş mantığının ön uçta çoğaltılmasını önler
• Tarayıcıda çok daha büyük bir HTTP yüküne neden olabilir. Yüksek bant genişliği bağlantısı olan bir masaüstünde kötü bir şey değil. Zayıf bir cep telefonunda çok kötü, 60mph'de pistte hızlanan bir acele saat treninde otururken ve diğer 1000 cep telefonu aynı anda bir hücre kulesinden ayrılıyor ve bir sonraki hücre kulesine yeniden bağlanmaya çalışıyor.

JSON sunma ve bir istemci tarafı şablonu oluşturma:

• HTML'den daha küçük bir HTTP yüküne neden olabilir, bu da uygulamanın güvenilmez veya yavaş ağ bağlantılarında daha duyarlı görünmesini sağlayabilir
• Birçok JavaScript şablon dili tam özelliklidir, yani yalnızca HTML oluşturmak için bir arka uca ihtiyacımız yoktur.

Bazen yeni JavaScript çerçevelerinin bebeği banyo suyuyla dışarı attığını düşünüyorum --- dostum umarım huysuz bir curmudgeon programcısı değilim ...

Son uygulamamda REST api ve JavaScript ön ucunu birleştirdim.

Yaptığım şey:

• CRUD işlemleri için bir REST API oluşturdum.
• Önceden tanımlanmış HTML şablonlarını yükleyen ve REST API'sinden döndürülen verilerle dolduran bir Javascript uygulaması oluşturdum.

Temel olarak JS ön ucu, CRUD işlemleri için REST API ile iletişim kurar ve HTML'leri döndürülen verilerle veya oluşturulan verilerle doldurur veya silinen verileri veya değiştirilen verileri günceller.

Böylece saf HTML var, istemci üzerinde işlem var, tüm HTML yüklemek zorunda kalmadan daha az bant genişliği kullanımı var ve kullanıcılara gerçekten Web 2.0 bir deneyim verebilir.

Güvenlik ve kod çoğaltma için ön uçta iş doğrulamaları yapmıyorum, çünkü herkes sunucuya göndermeden önce verileri değiştirebilir ve sunucudaki verileri tekrar doğrulamamız gerekir. Bu nedenle, bu kolayca hacklenebilir. Tüm doğrulama işlemleri arka uçta yapılır. İstemci tarafındaki doğrulamalar yalnızca girdi türleri için yapılır.

Artıları:

• JS tarafından oluşturulmadığı için HTML'de değişiklik yapma imkanı;
• Ajax ve JSON kullanarak daha düşük bant genişliği tüketimi;
• İstemci tarafında HTML bulunduğu için sunucu işlemede daha az tüketim;
• Ekranı değiştirmek, efektlerin kullanımına izin vermek ve oluşturma hızını arttırmak için JS kullanarak geliştirilmiş kullanıcı deneyimi.
• REST kullanarak HTTP protokolünü daha iyi kullanma.

Eksileri:

• 2 uygulama yapılacak;
• Kötü donanım nedeniyle kötü olabilecek istemci işlemesine bağlıdır.

Bu yardımcı olur umarım.

Saygılarımızla,

validationWeb Api yönü ile ilgili - "model doğrulama" yapmak ve 400 hatalı bir istek http yanıtı ile yanıtlamak mümkündür.

Bkz. Https://stackoverflow.com/questions/11686690/handle-modelstate-validation-in-asp-net-web-api/25050285#25050285