JSON yerine oluşturulan HTML'yi döndürmek neden kötü bir uygulamadır? Yoksa öyle mi?

JQuery veya benzer bir çerçeve kullanarak özel URL'lerinizden / Web hizmetlerinizden HTML içeriği yüklemek oldukça kolaydır. Bu yaklaşımı birçok kez ve şimdiye kadar kullandım ve performansı tatmin edici buldum.

Ancak tüm kitaplar, tüm uzmanlar, oluşturulan HTML yerine JSON'u kullanmamı sağlamaya çalışıyor. HTML'den çok daha üstün olan nedir?

Çok daha hızlı mı?
Sunucuda çok daha az yük var mı?

Diğer tarafta, oluşturulan HTML'yi kullanmak için bazı nedenlerim var.

1. Basit biçimlendirme ve genellikle JSON'dan daha kompakt veya aslında daha kompakt.
2. Daha az hata eğilimli çünkü aldığınız tek şey işaretleme ve kod yok.
3. Çoğu durumda programlamak daha hızlı olacaktır, çünkü istemci sonu için ayrı ayrı kod yazmak zorunda kalmazsınız.

Hangi taraftasın ve neden?

Aslında her iki tarafta da biraz varım:

• Javascript tarafında ihtiyacım olan veri olduğunda , JSON kullanıyorum
• Javascript tarafında ihtiyacım olan herhangi bir hesaplama yapmayacağım sunum olduğunda , genellikle HTML kullanın

HTML kullanmanın temel avantajı, sayfanızın tam bir bölümünü Ajax isteğinden geri gelenlerle değiştirmek istediğiniz zamandır:

• JS'de sayfanın bir bölümünü yeniden oluşturmak oldukça zor
• Muhtemelen sunucu tarafında zaten bir şablon var, bu ilk etapta sayfayı oluşturmak için kullanıldı ... Neden tekrar kullanmıyorsunuz?

Genellikle en azından sunucuda, şeylerin "performans" tarafını gerçekten dikkate almaz:

• Sunucuda, HTML'nin bir kısmını veya bazı JSON'ları oluşturmak, muhtemelen bu kadar büyük bir fark yaratmayacaktır.
• Ağ üzerinden geçen öğelerin boyutu hakkında: Eh, muhtemelen yüzlerce KB veri / html kullanmıyorsunuz ... Aktardığınız her şeyde gzip kullanmak, en büyük farkı yaratacak şeydir (HTML arasında seçim yapmamak) ve JSON)
• Dikkate alınabilecek bir şey , JSON verilerinden HTML'yi (veya DOM yapısını) yeniden oluşturmak için istemcide hangi kaynaklara ihtiyacınız olduğunu ... HTML'nin bir kısmını sayfaya itmekle karşılaştırın; -)

Son olarak, kesinlikle önemli olan bir şey:

• JS'nin veriyi sayfaya HTML olarak enjekte etmesi için gereken JSON + kodu olarak veri gönderecek yeni bir sistem geliştirmeniz ne kadar sürer?
• HTML'yi döndürmek ne kadar sürer? Halihazırda var olan sunucu tarafı kodlarınızdan bazılarını tekrar ne kadar süre kullanabilirsiniz?

Ve başka bir yanıtı cevaplamak için: sayfanın birden fazla bölümünü güncellemeniz gerekiyorsa, tüm bu parçaları birkaç HTML bölümünü gruplayan ve JS'de ilgili parçaları ayıklayan büyük bir dizenin içinde göndermenin çözümü / kesmek hala mevcuttur.

Örneğin, şuna benzer bir dize döndürebilirsiniz:

<!-- MARKER_BEGIN_PART1 -->
here goes the html
code for part 1
<!-- MARKER_END_PART1 -->
<!-- MARKER_BEGIN_PART2 -->
here goes the html
code for part 2
<!-- MARKER_END_PART2 -->
<!-- MARKER_BEGIN_PART3 -->
here goes the json data
that will be used to build part 3
from the JS code
<!-- MARKER_END_PART3 -->

Bu gerçekten iyi görünmüyor, ancak kesinlikle kullanışlı (çoğunlukla HTML verileri JSON içine alınamayacak kadar büyük olduğunda, birkaç kez kullandım) : sayfanın bölümleri için HTML gönderiyorsunuz sunum gerekiyor ve verilere ihtiyacınız olan durum için JSON gönderiyorsunuz ...

... Ve bunları çıkarmak için, JS alt dize yöntemi hile yapacak, sanırım ;-)

Esas olarak burada belirtilen görüşlere katılıyorum. Ben sadece onları şöyle özetlemek istedim:

• Üzerinde bazı hesaplamalar yapmak için istemci tarafında ayrıştırırsanız HTML göndermek kötü bir uygulamadır.

• Sonunda yapacağınız tek şey bunu sayfanın DOM ağacına dahil etmekse JSON göndermek kötü bir uygulamadır.

İyi,

Ben şeyleri bu şekilde ayırmak seven nadir kişilerden biriyim: - Sunucu veri (model) teslim sorumludur; - Müşteri verileri (model) göstermek (görüntülemek) ve işlemekten (model) sorumludur;

Bu nedenle, sunucu modeli teslim etmeye odaklanmalıdır (bu durumda JSON daha iyidir). Bu şekilde esnek bir yaklaşım elde edersiniz. Modelinizin görünümünü değiştirmek isterseniz, sunucunun aynı verileri göndermesini sağlar ve yalnızca bu verileri bir görünüme dönüştüren istemciyi, javascript bileşenlerini değiştirirsiniz. Masaüstü uygulamalarının yanı sıra mobil cihazlara da veri gönderen bir sunucunuz olduğunu düşünün.

Ayrıca, sunucu ve istemci kodu aynı anda oluşturulabildiğinden, js'den PHP / JAVA / vb.

Genellikle, çoğu insan sunucu tarafında mümkün olduğunca yapmayı tercih ettiğini düşünüyorum, çünkü js konusunda usta değiller, bu yüzden mümkün olduğunca kaçınmaya çalışırlar.

Temel olarak, Angular üzerinde çalışan adamlarla aynı görüşe sahibim. Bence bu web uygulamalarının geleceği.

Ekleyebileceğimi düşündüğüm ilginç bir şeyim var. Sadece bir kez tam görünüm yükleyen bir uygulama geliştirdim. Bu noktadan sonra sunucuya yalnızca ajax ile iletişim kurdu. Sadece bir sayfa yüklemek gerekiyordu (bunun sebebi burada önemsiz). İlginç kısmı, javascript üzerinde çalıştırılacak bazı verileri döndürmek için özel bir ihtiyaç vardı ve görüntülenecek kısmi bir görünüm geliyor. Bunu iki ayrı eylem yöntemine iki çağrıya bölebilirdim ama biraz daha eğlenceli bir şeyle gitmeye karar verdim.

Bunu kontrol et:

public JsonResult MyJsonObject(string someData)
{
     return Json(new { SomeData = someData, PartialView = RenderPartialViewToString("JsonPartialView", null) }, JsonRequestBehavior.AllowGet);
}

RenderPartialViewToString () nedir sorabilirsiniz? Buradaki bu küçük serinlik külçesi:

protected string RenderPartialViewToString(string viewName, object model)
{
     ViewData.Model = model;

     using (StringWriter sw = new StringWriter())
     {
          ViewEngineResult viewResult = ViewEngines.Engines.FindPartialView(ControllerContext, viewName);
          ViewContext viewContext = new ViewContext(ControllerContext, viewResult.View, ViewData, TempData, sw);
          viewResult.View.Render(viewContext, sw);

          return sw.GetStringBuilder().ToString();
     }
}

Bu konuda herhangi bir performans testi yapmadım, bu yüzden JsonResult için bir eylem yöntemi ve ParticalViewResult için bir eylem yöntemi çağırmak daha fazla veya daha az ek yüke neden olup olmadığından emin değilim, ama yine de oldukça serin olduğunu düşündüm. Kısmi bir görünümü bir dizeye serileştirir ve Json ile birlikte parametrelerinden biri olarak gönderir. Daha sonra bu parametreyi almak ve uygun DOM düğüme tokat JQuery kullanın :)

Melezim hakkında ne düşündüğünü söyle!

Yanıtın başka bir istemci tarafı işlemeye ihtiyacı yoksa, bence HTML tamam. JSON göndermek sizi yalnızca o istemci tarafı işlemeyi yapmaya zorlayacaktır.

Öte yandan, tüm yanıt verilerini aynı anda kullanmak istemediğimde JSON kullanıyorum. Örneğin, üç zincirli seçim dizim var, burada birinin seçilen değeri ikinciyi doldurmak için hangi değerlerin kullanılacağını belirler, vb.

IMV, her şey verileri verilerin sunumundan ayırmakla ilgili, ancak Pascal ile birlikteyim, ayırmanın sadece istemci / sunucu sınırı boyunca olabileceği anlamına gelmiyor. Bu ayırmaya zaten sahipseniz (sunucuda) ve istemciye yalnızca bir şey göstermek istiyorsanız, JSON'u geri gönderip istemciye sonradan işliyor veya yalnızca HTML'yi geri gönderip göndermediğiniz tamamen tamamen ihtiyaçlarınıza bağlıdır. Genel durumda HTML göndermek için "yanlış" demek için IMV bir açıklama çok battaniye.

JSON çok yönlü ve hafif bir formattır. Bir istemci tarafı şablon ayrıştırıcısı veri olarak kullanmaya başladığımda güzelliğini keşfettim. Sunucu tarafında akıllıca ve görünümler kullanmadan önce (yüksek sunucu yükü üretirken), şimdi bazı özel jquery işlevlerini kullanıyorum ve tüm veriler istemci tarafında, şablon ayrıştırıcısı olarak istemciler tarayıcısı kullanılarak işleniyor. sunucu kaynakları kurtarır ve diğer yandan tarayıcılar her gün JS motorlarını geliştirir. Bu nedenle, müşteri ayrıştırma hızı şu anda önemli bir sorun değil, daha da fazlası, JSON nesneleri genellikle çok küçüktür, bu nedenle çok fazla istemci tarafı kaynağı tüketmezler. Çok yüklü sunucu nedeniyle herkes için yavaş site yerine yavaş tarayıcılı bazı kullanıcılar için yavaş bir web sitesine sahip olmayı tercih ederim.

Diğer taraftan, sunumdan soyutlaştırdığınız sunucudan saf veri göndermek, böylece yarın değiştirmek veya verilerinizi başka bir hizmete entegre etmek istiyorsanız, bunu çok daha kolay yapabilirsiniz.

Sadece 2 sentim.

Bence en iyi uygulama olan temiz bir ayrıştırılmış istemci istiyorsanız, o zaman javascript tarafından oluşturulan DOM% 100 olması mantıklı. Kullanıcı arabirimini nasıl oluşturacağınızı bilen bir MVC tabanlı istemci oluşturursanız, kullanıcılarınız bir kez bir javascript dosyası indirir ve istemcide önbelleğe alınır. Bu ilk yüklemeden sonraki tüm istekler Ajax tabanlıdır ve yalnızca veri döndürür. Bu yaklaşım bulduğum en temiz yaklaşımdır ve sunumun temiz bağımsız bir kapsüllenmesini sağlar.

Sunucu tarafı daha sonra sadece veri dağıtımına odaklanır.

Bu yüzden yarın ürün sizden bir sayfanın tasarımını tamamen değiştirmenizi istediğinde, tüm yaptığınız DOM'u oluşturan kaynak JS'dir, ancak zaten mevcut olay işleyicilerinizi yeniden kullanacaksınız ve sunucu% 100 sunumdan ayrıldığı için kayıtsızdır.

Kullanıcı arayüzünüze bağlı olarak, DOM'nizdeki iki (veya daha fazla) farklı öğeyi güncellemeniz gerekebilir. Yanıtınız HTML'deyse, nereye gittiğini anlamak için bunu ayrıştıracak mısınız? Veya sadece bir JSON karması kullanabilirsiniz.

Hatta birleştirebilir, html verileri ile bir JSON döndürebilirsiniz :)

{ 'dom_ele_1' : '<p>My HTML part 1</p>', 'dome_ele_2' : '<div>Your payment has been received</div>' }

HTML birçok gereksiz ve görüntülenmeyen veri yani etiketleri, stil sayfaları vb vardır. Böylece JSON verileri ile karşılaştırıldığında HTML boyutu daha büyük olacak daha fazla indirme ve oluşturma süresi de tarayıcı yeni verileri oluşturma meşgul neden olur.

Json gönderme genellikle sunucudan liste veya ağaç görünümü veya otomatik tamamlama gibi bilgi isteyen bir javascript widget'iniz olduğunda yapılır. Bu ayrıştırılacak ve ham kullanılacak veri olduğu gibi JSON göndermek istiyorum. Ancak, HTML'nizi gösterecekseniz, sunucu tarafı oluşturmak ve sadece tarayıcıda göstermek için çok daha az iş. Tarayıcılar, innerHTML = "" ile HTML'yi doğrudan dom'a eklemek için optimize edilmiştir, böylece yanlış gidemezsiniz.

Tasarımın yapısına bağlı olduğunu düşünüyorum, HTML'den JSON kullanmak sadece daha seksi, ancak soru nasıl idare edileceği, böylece bakımı kolay olabilir.

Örneğin, tüm sitenin aynı html / stilini kullanan liste sayfam olduğunu varsayalım, bu HTML bölümlerini biçimlendirmek için global işlevi yazarım ve tek yapmam gereken JSON nesnesini işleve geçirmektir.

İstemci tarafında bazı hesaplamalar yapmanız gerekmediği sürece, çoğu durumda Html yanıtı yeterlidir.

Koşullara bağlıdır.

Bazen JSON'dan kaçınmak gerekir. Örneğin programcılarımız js'de programlamada sorun yaşadıklarında.

Deneyimlerim bana şunu söylüyor: ajax hizmetini satır içi JSON'dan daha iyi kullan.

Er ya da geç js sorun oluyor