HTML / JavaScript'in yalnızca web uygulamasının avantajları ve dezavantajları [kapalı]


35

Bir ASP.NET form arka planından geliyorum ve sunucu tarafında kodlamanın geçmişte çok güçlü olduğunu gördüm. Ancak daha yakın zamanlarda, ön uçtaki sunucu tarafı kodunu değiştirmek ve yerine JSON web servisleriyle erişen saf HTML / JavaScript ile değiştirmek istiyordum. Bu konuda gerçek bir deneyimim yok ve bu yüzden denenmiş ve test edilmiş bir model olup olmadığını duymak istiyorum. Ayrıca, onu çevreleyen tuzaklar nelerdir?

ASP.NET kullanıcı kontrollerini çok yararlı buluyorum, bu yüzden işaretleme şablonlarını sunucudaki ayrı HTML dosyalarında saklayarak teorisini bunun arkasında tutmak istiyorum. Bunlar, sırasıyla jQuery AJAX ve jQuery HTML templates plugin'i aracılığıyla alınacak ve kullanılacaktır.

Herhangi bir giriş son derece takdir edilecektir.

PS Noob sorusu için üzgünüm, ama bu tür bir Web mimarisi web 2.0 olarak adlandırılan şey mi, yoksa tam izini süremiyorum?


1
ASP.NET denetimlerini HTML / JavaScript ile değiştirmek mi istiyorsunuz yoksa tüm işletme mantığını (doğrulama vb.) Ön uçta mı göstermek istiyorsunuz?
šljaker

1
İyi soru. Sayfayı aydınlatmak için cep telefonlarında / pedlerde daha hızlı olması için sadece html / javascript ile ön yüz yapmayı düşünüyorum. Bu yüzden muhtemelen sadece asp.net denetimlerinin yerine geçer. Tüm web sunucusu üzerinden sunucuya yapılan aramalar, bu nedenle wcf servisi bir şekilde doğrulama ile ilgilenmelidir. Bunun mümkün olduğunu düşünüyor musunuz?
hofnarwillie


Doğrulama için @hofnarwillie, müşteri tarafı JS kullanmanız gerektiğini düşünüyorum.
smwikipedia

1
@smwikipedia Teşekkürler, ancak müşteri tarafı doğrulamasının sadece kullanıcıların kolaylığı için kullanılması gerektiğini biliyorum. Gerçek doğrulama sunucu tarafında yapılmalıdır. Müşteri tarafı doğrulaması, uygulamanızı kullanıcı dostu yapar, ancak sunucu tarafı doğrulaması güvenlik ve geçerlilik sağlar, çünkü müşteri tarafı doğrulaması kolayca kapatılabilir.
hofnarwillie

Yanıtlar:


31

Bu tekniği yalnızca üzerinde çalıştığımız bir web uygulaması için kullandım. Arka uçlarım Java SDK kullanılarak Google App Engine'de barındırılıyor ve ön uçlarım HTML, CSS ve JavaScript kullanıyor (jQuery ile).

Proje sadece kendim ve bir Web tasarımcısı ile daha küçük bir proje ve ikimiz de bu yöntemin çok daha hızlı çalışmamıza ve çok daha kısa sürede pazarlamak için bir şeyler almamıza yardımcı olduğunu düşünüyoruz.

Avantaj: Web Tasarımcılarıyla Çalışma

Bu tekniğin en büyük avantajı, PHP'yi tanıyan, ancak kendisini bir programcı olarak görmeyen Web tasarımcısının, HTML ve CSS'de sayısız JSP, taglib etiketi ve diğer sunucu tarafı satırlarında gezinmek zorunda kalmadan numarasız çalışabilmesidir. Yıllardır bize söylenen işaretleme, bir ön uç geliştiricinin hayatını daha kolay hale getirmesi gerekiyor .

Tüm sunucu tarafı işaretlemesi olmadan, daha çevik davrandık. Web tasarımcısı doğrudan değiştirdi ve orijinal tasarımını 3 ya da 4 kez revize etti ve çok az değişiklik yaptı.

Bana yaptığı yorum, HTML'nin onu düzenleyebileceğini ve makinedeki değişiklikleri dinamik verilerle hemen görebildiğini yaşıyormuş gibi hissettiğini söyledi. Bütünleşmenin çoğunlukla otomatik olması nedeniyle ikimiz de fayda sağladık.

Sunucu tarafı kodu ve HTML / CSS Handoffs

Geçmiş projelerde, HTML ve CSS’yi Java geliştiricilere devretmek zorunda kalıyordu; Bu çok zaman alır ve genellikle W3C doğrulayıcısındaki onaylamanın yanı sıra sayfaların gerçek görüntülemesinde ince ancak önemli farklara neden olur.

Genel olarak, bu teknikten ikimiz de çok memnunuz ve HTML sayfalarımda hala sıfır JSP sayfam veya sunucu tarafı kodum var.

REST / JSON Tekniğinin Tuzaklar

Belki de en büyük tuzaklar, henüz karşılaşmadığımızlardır. Apache'nin ve Spring ekibinin kendilerine etiket kütüphanelerinin etiket kütüphanelerinin ön uç geliştiricilerin kodla çalışmasını nasıl kolaylaştıracağı konusunda söylediklerinin beynini yıkadığı konusunda daha fazla tecrübeli Java geliştiricileri ile bazı anlaşmazlıklar yaşamalarını bekliyorum. Bu proje genişlediğinden ve deneyimlerime göre Web tasarımcılarının işini zorlaştıran bu eski teknikleri öğrenmek zorunda kalabilecek daha fazla geliştiriciyi benimsemeyi tam olarak bekliyorum .

Başka bir tuzak, JavaScript kodunun çok büyük hale gelmesidir. Bu belki de daha büyük bir problem, çünkü bu tekniği ilk defa kullanıyorum ve hızlı bir sürüm için biraz teknik borç aldık. Belki de daha iyi bir çerçeve seçmek, kodun büyük bölümünün çoğunun hafifletilmesine yardımcı olabilirdi. Benim düşünceme göre, bunların hiçbiri bir gösteri olmadı ve bu tekniği kullanmaya devam etmem ve bu alandaki becerilerimi geliştirmem için cesaretlendirildim.

Avantaj: Platform Üzerine Diğer Uygulamalar Yapılabilir

Son olarak, gizli bir avantajdan bahsetmeliyim. Arka uç RESTful Web servislerim ve ön uçum arasında hoş bir ayrılık olduğu için, kolayca genişletebileceğim bir platform da oluşturdum.

Operasyon adamlarımızdan biri başka bir uygulamada konsept kanıtını denemek istedi ve RESTful servislerim sayesinde, tamamen farklı bir sorunu çözmek için uygulamaya tamamen farklı bir ön uç oluşturabildik. Hızla geliştirilen konsept kanıtı, kendi HTML, CSS ve JavaScript'ini kullandı, ancak RESTful servislerini arka uç ve veri kaynağı olarak kullandı.

Sonunda, başka bir proje yöneticisi ne yaptığımı gördü ve bu özelliğin bir kavram kanıtından daha fazlası olması gerektiği hemen anlaşıldı ve ekibi uyguladı.

Hem uygulama düzeyinde hem de HTML / CSS / JavaScript düzeyinde bu mimarinin ne kadar tekrar kullanılabilir olduğunu yeterince vurgulayamıyorum ve bunu bir sonraki projenizde kesinlikle denemenizi tavsiye ederim.


2
Teşekkür ederim. Bu sorumu tamamen cevaplıyor. Net ve özlü bir cevap vererek harcadığınız zamanı takdir edin. +1
hofnarwillie

2
Tüm web uygulamalarının html / js olduğu, sadece json kodlu verilere hizmet veren arka uç servisleriyle çalıştığım bir şirkette çalışıyorum. Bu model kullanılarak yeni uygulamalar oluşturmak için gerçekten iyi çalışıyor ve çok daha hızlı çalışıyor. paralel. Bunu gerçekten denemelisin.
nohros

@ jmort253 Mükemmel cevap için çok teşekkürler. Tamamen aynı mimariyi düşünüyordum ve uygulaman beni onunla devam edeceğine inandırıyor. Burada da benzer sorular sordum: stackoverflow.com/questions/33934101/… ve burada: stackoverflow.com/questions/34020543/… .
smwikipedia

12

Bu kesinlikle uygulanabilir bir strateji, ancak gümüş bir kurşun değil.

Artıları :

  • doğru yapılırsa, bu şekilde geliştirilen uygulamalar çok duyarlı
  • mantık (sunucuda) ve sunum (istemcide) arasında açık bir ayrımınız var; Sunucunun, uygulamanın sunum yönleriyle hiç bir şekilde ilgilenmesi gerekmez.
  • ağ bant genişliğinin potansiyel olarak daha verimli kullanımı (yalnızca ham veri gönderiyorsunuz, sunum metni yok)
  • masaüstüne benzeyen GUI'ler geliştirmek daha kolay, çünkü istek / yanıt paradigmasına daha az bağımlısınız

Eksileri :

  • İstemci kodunuzu Javascript'e veya Javascript'i derleyebilecek bir dilde yazmanız gerekir, çünkü tarayıcıda mevcut olan tek şey budur.
  • istemcideki kaynak kullanımı daha yüksek olabilir, bu nedenle uygulama standart altı cihazlarda iyi çalışmayabilir (mobil tarayıcıları düşünün vb.)
  • javascript devre dışı bırakıldığında hiç çalışmaz; halka açık bir web sitesi varsa, bu riski almak isteyip istemediğinizi zor düşünmelisiniz (özellikle SEO ve erişilebilirliği düşünüyorsanız - javascript ağırlıklı bir yaklaşım genellikle bu iki cephede yıkıcıdır)
  • çok fazla mantık iki kez yazılmalıdır: istemcide bir kez ve bir kez daha sunucuda (istemciye asla güvenemezsiniz)
  • eşzamanlılık cehennem olabilir, bu nedenle müşteri tarafı kodunuzu çok dikkatli bir şekilde tasarlamanız ve her türlü eşzamanlılık sorununa hazırlıklı olmanız gerekir.

2
Teşekkürler. Bu modelin neden olacağı eşzamanlılık sorunlarına bir örnek verebilir misiniz?
hofnarwillie

3
Örnek: Kullanıcı Oy Ver'i tıklatırsa ve ardından Oy Verme sunucusu çağrısı sona ermeden önce hemen Oy Ver'i tıklatırsa, kaç oy var?
JBRWilkinson

@JBRWilkinson Durum veya zaman aşımı veya aralık kontrolü yapan Boole bayrağı?
Alper Turan

1

Bu kesinlikle mümkün ve muhtemelen en iyi uygulama olarak teşvik edilebilir. Teklif ettiğiniz şey kullanıcı arayüzünü işletme mantığından ayırmak, böylece kaygılarınızı net bir şekilde ayırmanız için. Bu gerçekten iyi.

Sıklıkla, işleri bir araya getirmeye çalıştığımız çerçeveler ve UI, işletme mantığı ve verilerin birbirleriyle iç içe geçtiği yekpare bir yazılım parçası ile sonuçlanırsınız. Bu, bakımı ve değiştirmeyi zorlaştırır.

Uygulamayı 2 parçaya böldüğünüzde, kullanıcı arayüzünü tamamen başka bir şeyle değiştirebilirsiniz - bir masaüstü programı veya mobil tarayıcılar ile karşılaştırıldığında mobil için başka bir kullanıcı arayüzü.

Bunu yaparken bulacağınız zor bitler, teorik olarak sunucuda bulunması gereken kodun müşteriye daha iyi yerleştirilmesi gerektiğidir - örneğin doğrulama, kullanıcının doğrulama kodunu koyması için daha hızlı ve daha hızlı yanıt vermesi İstemcideki formu kontrol etmek, sunucuya çarpmak demek, yani bir metin alanı sadece alfasayısal karakterler içeriyor. Aynısı veri ve iş katmanları için de geçerlidir. Sadece katmanlar arasındaki ayrımı ne zaman ihlal edeceğiniz konusunda bilinçli ve pratik kararlar vermelisiniz.


1

Bir dezavantajı, mantığın bazılarını JavaScript ve ASP.net'te çoğaltmak zorunda kalıyor. Başvurunuza bağlı olarak bu sizin için büyük bir sorun olmayabilir. Sık sık ortaya çıkar, çünkü sunucudan her küçük şeyi kontrol etmesini istemek zorunda kalmazsınız ("Bu durumda kullanıcının bu düğmeye basmasına veya bu seçeneği seçmesine izin veriyor mu?") Ama aynı zamanda bağımlı olmak da istemezsiniz. İstemcide, kullanıcı istemciyi kontrol ettiği için doğrulama yapan tek kişi olarak.


0

Hala ASP.NET WebForms kullanıyorsanız ve uygulamalarınızı hızlandırmak istiyorsanız, yapmanız gerekenler:

  • Uygulamanızı SOLID düşünülerek tasarlayın
  • ViewStateTüm sayfalarda ve kullanıcı kontrollerinde devre dışı bırak
  • Sunucu tarafı denetimlerini kullanma

    <%: VeiwModel.Title%> yerine <asp: Literal id = "Title" runat = "server">

  • Arka uçta, OnInit yöntemini geçersiz kıl ve tüm başlatmalarını burada yap:

    korumalı geçersiz kılma geçersiz kılma OnInit (System.EventArgs e) {CreateViewModel (); (E) base.OnInit; }

  • Tüm .css ve .js dosyalarını SquishIt kullanarak 1'e sıkıştırın.

  • Tembel yük görüntüleri
  • Karmaşık nesneleri önbelleğe al

Son olarak, www.porsche.se adresini ziyaret edin. Bu hızlı bir web sitesi değil mi?


Bu gerçekten hızlı bir web sitesi. Giriş için çok teşekkürler. Çok takdir.
hofnarwillie
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.