ทำไมการคืน HTML ที่สร้างขึ้นแทนที่จะเป็น JSON หรือมันคืออะไร?

ค่อนข้างง่ายในการโหลดเนื้อหา HTML จาก URL ที่กำหนดเอง / บริการบนเว็บของคุณโดยใช้ JQuery หรือกรอบงานอื่นที่คล้ายคลึงกัน ฉันใช้วิธีนี้หลายครั้งจนถึงตอนนี้และพบว่าประสิทธิภาพเป็นที่น่าพอใจ

แต่หนังสือทั้งหมดผู้เชี่ยวชาญทั้งหมดพยายามให้ฉันใช้ JSON แทน HTML ที่สร้างขึ้น มันยอดเยี่ยมกว่า HTML มากอย่างไร

เร็วขึ้นมากไหม
มันมีโหลดที่น้อยกว่ามากบนเซิร์ฟเวอร์หรือไม่

ในอีกด้านฉันมีเหตุผลบางอย่างสำหรับการใช้ HTML ที่สร้างขึ้น

1. มันเป็นมาร์กอัปธรรมดาและมักจะกะทัดรัดหรือจริงแล้วกะทัดรัดกว่า JSON
2. เป็นข้อผิดพลาดน้อยที่ทำให้เกิดสิ่งที่คุณได้รับคือมาร์กอัปและไม่มีรหัส
3. มันจะเร็วกว่าในการเขียนโปรแกรมในกรณีส่วนใหญ่ทำให้คุณไม่ต้องเขียนโค้ดแยกต่างหากสำหรับการสิ้นสุดของไคลเอ็นต์

คุณอยู่ด้านไหนและทำไม

จริง ๆ แล้วฉันเป็นทั้งสองด้าน:

• เมื่อสิ่งที่ฉันต้องการในด้านจาวาสคริปต์คือข้อมูลฉันใช้ JSON
• เมื่อสิ่งที่ฉันต้องการในด้านจาวาสคริปต์คือการนำเสนอที่ฉันจะไม่ทำการคำนวณใด ๆ ฉันมักใช้ HTML

ข้อได้เปรียบหลักของการใช้ HTML คือเมื่อคุณต้องการแทนที่ส่วนเต็มของหน้าของคุณด้วยสิ่งที่กลับมาจากคำขอ Ajax:

• การสร้างบางส่วนของหน้าใน JS นั้นค่อนข้างยาก
• คุณอาจมีเอ็นจิ้นการสร้างเทมเพลตไว้ที่ฝั่งเซิร์ฟเวอร์แล้วซึ่งใช้ในการสร้างหน้าเว็บในตอนแรก ... ทำไมไม่ลองใช้ซ้ำ

ฉันมักจะไม่คำนึงถึงด้าน "ประสิทธิภาพ" ของสิ่งต่าง ๆ อย่างน้อยบนเซิร์ฟเวอร์:

• บนเซิร์ฟเวอร์การสร้างส่วนของ HTML หรือ JSON บางอย่างอาจไม่สร้างความแตกต่างมากนัก
• เกี่ยวกับขนาดของสิ่งของที่ต้องผ่านเครือข่าย: คุณอาจไม่ได้ใช้ข้อมูล / html หลายร้อย KB ... การใช้ gzip กับทุกสิ่งที่คุณกำลังถ่ายโอนคือสิ่งที่จะสร้างความแตกต่างที่ยิ่งใหญ่ที่สุด(ไม่เลือกระหว่าง HTML และ JSON)
• สิ่งหนึ่งที่สามารถนำมาพิจารณาได้คือทรัพยากรที่คุณต้องมีเพื่อสร้าง HTML (หรือโครงสร้าง DOM)จากข้อมูล JSON ... เปรียบเทียบว่าจะผลักส่วน HTML ลงในหน้า -)

ในที่สุดสิ่งหนึ่งที่สำคัญอย่างแน่นอน:

• ใช้เวลานานแค่ไหนในการพัฒนาระบบใหม่ที่จะส่งข้อมูลในรูปแบบ JSON + รหัสที่ JS ต้องการเพื่อใช้เป็น HTML ในหน้าเว็บ?
• ต้องใช้เวลานานแค่ไหนในการส่งคืน HTML และนานแค่ไหนถ้าคุณสามารถใช้รหัสฝั่งเซิร์ฟเวอร์ที่มีอยู่แล้วบางส่วนได้?

และเพื่อตอบคำตอบอื่น: หากคุณต้องการอัปเดตมากกว่าหนึ่งส่วนของหน้ายังคงมีวิธีแก้ปัญหา / แฮ็กในการส่งชิ้นส่วนเหล่านั้นทั้งหมดภายในสตริงใหญ่อันเดียวที่จัดกลุ่ม HTML หลายส่วนและแยกส่วนที่เกี่ยวข้องใน JS

ตัวอย่างเช่นคุณสามารถส่งคืนสตริงที่มีลักษณะดังนี้:

<!-- 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 -->

มันไม่ได้ดูดีจริงๆ แต่มันมีประโยชน์แน่นอน(ฉันใช้มันค่อนข้างสองครั้งส่วนใหญ่เมื่อข้อมูล HTML มีขนาดใหญ่เกินไปที่จะถูกห่อหุ้มใน JSON) : คุณกำลังส่ง HTML สำหรับส่วนของหน้าเว็บที่ ต้องการงานนำเสนอและคุณกำลังส่ง JSON สำหรับสถานการณ์ที่คุณต้องการข้อมูล ...

... และเพื่อแยกสิ่งเหล่านั้นวิธีย่อย JS จะทำเคล็ดลับฉันคิดว่า ;-)

ฉันเห็นด้วยกับความคิดเห็นที่ระบุไว้ที่นี่เป็นหลัก ฉันแค่ต้องการสรุปพวกเขาเป็น:

• การส่ง HTML เป็นเรื่องที่ไม่ถูกต้องหากคุณแยกวิเคราะห์ฝั่งไคลเอ็นต์เพื่อทำการคำนวณบางอย่าง

• เป็นการดีที่จะส่ง JSON หากสิ่งที่คุณจะทำคือการรวมไว้ในทรี DOM ของหน้า

ดี,

ฉันเป็นหนึ่งในคนที่หายากที่ชอบแยกสิ่งนี้ด้วยวิธีนี้: - เซิร์ฟเวอร์รับผิดชอบการส่งข้อมูล (รุ่น); - ลูกค้ามีหน้าที่รับผิดชอบในการแสดง (ดู) และจัดการข้อมูล (รุ่น);

ดังนั้นเซิร์ฟเวอร์ควรให้ความสำคัญกับการนำเสนอโมเดล (ในกรณีนี้ JSON ดีกว่า) ด้วยวิธีนี้คุณจะได้รับแนวทางที่ยืดหยุ่น หากคุณต้องการเปลี่ยนมุมมองของแบบจำลองของคุณคุณเก็บเซิร์ฟเวอร์ที่ส่งข้อมูลเดียวกันและเพียงแค่เปลี่ยนลูกค้าส่วนประกอบจาวาสคริปต์ที่เปลี่ยนข้อมูลนั้นเป็นมุมมอง ลองนึกภาพคุณมีเซิร์ฟเวอร์ที่ส่งข้อมูลไปยังอุปกรณ์มือถือเช่นเดียวกับแอปบนเดสก์ท็อป

นอกจากนี้วิธีการนี้ยังเพิ่มประสิทธิภาพการทำงานเนื่องจากสามารถสร้างเซิร์ฟเวอร์และรหัสลูกค้าได้ในเวลาเดียวกันไม่ต้องเสียสมาธิซึ่งเป็นสิ่งที่เกิดขึ้นเมื่อคุณเปลี่ยนจาก js เป็น PHP / JAVA / เป็นต้น

โดยทั่วไปฉันคิดว่าคนส่วนใหญ่ชอบทำมากที่สุดเท่าที่จะทำได้บนฝั่งเซิร์ฟเวอร์เพราะพวกเขาไม่ใช่ผู้เชี่ยวชาญ js ดังนั้นพวกเขาจึงพยายามหลีกเลี่ยงให้มากที่สุด

โดยพื้นฐานแล้วฉันมีความคิดเห็นเช่นเดียวกับพวกที่ทำงานเกี่ยวกับ Angular ในความคิดของฉันที่เป็นอนาคตของเว็บแอพ

ฉันมีสิ่งที่น่าสนใจฉันคิดว่าฉันอาจเพิ่ม ฉันพัฒนาแอปพลิเคชันที่เคยโหลดมุมมองแบบเต็มครั้งเดียวเท่านั้น จากจุดนั้นไปข้างหน้ามันสื่อสารกลับไปที่เซิร์ฟเวอร์ด้วย ajax เท่านั้น จำเป็นต้องโหลดหน้าเดียวเท่านั้น (เหตุผลของฉันสำหรับเรื่องนี้ไม่สำคัญที่นี่) ส่วนที่น่าสนใจมาในที่ฉันมีความต้องการพิเศษในการส่งคืนข้อมูลบางส่วนที่จะดำเนินการในจาวาสคริปต์และมุมมองบางส่วนที่จะแสดง ฉันสามารถแบ่งออกเป็นสองสายเป็นสองวิธีการดำเนินการแยกกัน แต่ฉันตัดสินใจที่จะไปกับสิ่งที่สนุกมากขึ้นเล็กน้อย

ลองดูสิ:

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

คุณอาจถามว่า RenderPartialViewToString () คืออะไร มันคือนักเก็ตตัวยงของความเท่นี่:

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();
     }
}

ฉันยังไม่ได้ทำการทดสอบประสิทธิภาพใด ๆ เกี่ยวกับเรื่องนี้ดังนั้นฉันจึงไม่แน่ใจว่ามันจะเกิดค่าใช้จ่ายมากหรือน้อยกว่าการเรียกวิธีการหนึ่งในการดำเนินการสำหรับ JsonResult และอีกวิธีหนึ่งสำหรับ ParticalViewResult แต่ฉันก็ยังคิดว่ามันค่อนข้างเท่ห์ มันแค่เรียงลำดับมุมมองบางส่วนเป็นสตริงและส่งไปพร้อมกับ Json เป็นหนึ่งในพารามิเตอร์ จากนั้นฉันใช้ JQuery เพื่อรับพารามิเตอร์นั้นและตบมันเป็นโหนด DOM ที่เหมาะสม :)

แจ้งให้เราทราบว่าคุณคิดอย่างไรกับลูกผสมของฉัน!

หากการตอบสนองนั้นไม่ต้องการการประมวลผลฝั่งไคลเอ็นต์เพิ่มเติม HTML ก็ถือว่าใช้ได้ การส่ง JSON จะบังคับให้คุณทำการประมวลผลฝั่งไคลเอ็นต์เท่านั้น

ในทางกลับกันฉันใช้ JSON เมื่อฉันไม่ต้องการใช้ข้อมูลตอบกลับทั้งหมดพร้อมกัน ตัวอย่างเช่นฉันมีชุดของตัวเลือกที่ถูกล่ามโซ่สามชุดโดยที่ค่าที่เลือกของตัวเลือกหนึ่งจะกำหนดว่าจะใช้ค่าใดสำหรับการเติมค่าที่สองเป็นต้น

IMV มันคือทั้งหมดที่เกี่ยวกับการแยกข้อมูลจากการนำเสนอข้อมูล แต่ฉันกับ Pascal ไม่จำเป็นต้องทำตามว่าการแยกนั้นสามารถข้ามขอบเขตไคลเอ็นต์ / เซิร์ฟเวอร์ได้เท่านั้น หากคุณมีการแยกนั้นแล้ว (บนเซิร์ฟเวอร์) และเพียงต้องการแสดงบางสิ่งแก่ลูกค้าไม่ว่าคุณจะส่ง JSON กลับมาและดำเนินการกับลูกค้าหรือเพียงแค่ส่ง HTML กลับขึ้นอยู่กับความต้องการของคุณทั้งหมด ในการบอกว่าคุณ "ผิด" ในการส่ง HTML กลับในกรณีทั่วไปนั้นค่อนข้างคลุมงบ IMV มากเกินไป

JSON เป็นรูปแบบที่ตรงกันข้ามและมีน้ำหนักเบามาก ฉันได้ค้นพบความสวยงามของมันเมื่อฉันเริ่มใช้มันเป็นข้อมูลแยกวิเคราะห์แม่แบบฝั่งไคลเอ็นต์ ให้ฉันอธิบายก่อนที่ฉันจะใช้ smarty และมุมมองด้านเซิร์ฟเวอร์ (สร้างภาระเซิร์ฟเวอร์สูง) ตอนนี้ฉันใช้ฟังก์ชั่น jquery ที่กำหนดเองและข้อมูลทั้งหมดจะถูกแสดงในฝั่งไคลเอ็นต์โดยใช้เบราว์เซอร์ไคลเอ็นต์เป็นตัวแยกวิเคราะห์แม่แบบ มันช่วยประหยัดเซิร์ฟเวอร์ resourses และเบราว์เซอร์อื่น ๆ ปรับปรุงเครื่องมือ JS ของพวกเขาทุกวัน ดังนั้นความเร็วในการแยกวิเคราะห์ไคลเอนต์จึงไม่ใช่ประเด็นสำคัญในตอนนี้ยิ่งไปกว่านั้นวัตถุ JSON นั้นมีขนาดเล็กมากโดยทั่วไปดังนั้นพวกเขาจึงไม่ใช้การโต้ตอบด้านลูกค้าจำนวนมาก ฉันชอบที่จะมีเว็บไซต์ช้าสำหรับผู้ใช้บางคนที่มีเบราว์เซอร์ช้ามากกว่าเว็บไซต์ช้าสำหรับทุกคนเพราะเซิร์ฟเวอร์โหลดมาก

ในอีกทางหนึ่งการส่งข้อมูลบริสุทธิ์จากเซิร์ฟเวอร์ที่คุณสรุปได้จากการนำเสนอดังนั้นหากพรุ่งนี้คุณต้องการเปลี่ยนหรือรวมข้อมูลของคุณเข้ากับบริการอื่นคุณสามารถทำได้ง่ายขึ้นมาก

แค่ 2 เซ็นต์ของฉัน

หากคุณต้องการไคลเอนต์ที่แยกออกจากกันซึ่งในความคิดของฉันเป็นวิธีปฏิบัติที่ดีที่สุดแล้วมันก็สมเหตุสมผลที่จะมี 100% ของ DOM ที่สร้างขึ้นโดย javascript หากคุณสร้างไคลเอนต์ที่ใช้ MVC ซึ่งมีความรู้ทั้งหมดเกี่ยวกับวิธีสร้าง UI ผู้ใช้ของคุณจะดาวน์โหลดไฟล์ javascript หนึ่งไฟล์ในครั้งเดียวและถูกแคชไว้บนไคลเอนต์ คำขอทั้งหมดหลังจากการโหลดเริ่มต้นนั้นเป็นไปตาม Ajax และส่งคืนข้อมูลเท่านั้น วิธีนี้เป็นวิธีที่สะอาดที่สุดที่ฉันค้นพบและให้การห่อหุ้มที่เป็นอิสระจากการนำเสนอ

ฝั่งเซิร์ฟเวอร์นั้นจะมุ่งเน้นไปที่การส่งข้อมูล

ดังนั้นในวันพรุ่งนี้เมื่อผลิตภัณฑ์ขอให้คุณเปลี่ยนการออกแบบของหน้าอย่างสมบูรณ์ทั้งหมดที่คุณเปลี่ยนคือซอร์ส JS ที่สร้าง DOM แต่มีแนวโน้มที่จะใช้ตัวจัดการเหตุการณ์ที่มีอยู่แล้วของคุณและเซิร์ฟเวอร์จะลืมเลือนเพราะมัน 100% แยกจากงานนำเสนอ

คุณอาจต้องอัปเดตองค์ประกอบที่แตกต่างกันสองรายการขึ้นไปใน UI ของคุณทั้งนี้ขึ้นอยู่กับ UI ของคุณ หากคำตอบของคุณเป็น HTML คุณจะแยกวิเคราะห์เพื่อหาว่าเกิดอะไรขึ้น หรือคุณสามารถใช้แฮช JSON

คุณยังสามารถรวมมันคืนค่าข้อมูล JSON ด้วย html :)

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

HTML มีข้อมูลซ้ำซ้อนจำนวนมากและไม่แสดงข้อมูลเช่นแท็กสไตล์ชีทเป็นต้นดังนั้นขนาด HTML เมื่อเทียบกับข้อมูล JSON จะยิ่งใหญ่กว่าทำให้มีเวลาดาวน์โหลดและแสดงผลมากขึ้นและจะทำให้เบราว์เซอร์ไม่ว่างในการแสดงข้อมูลใหม่

โดยทั่วไปแล้วการส่ง json จะกระทำเมื่อคุณมีวิดเจ็ต javascript ที่ร้องขอข้อมูลจากเซิร์ฟเวอร์เช่นรายการหรือมุมมองแบบต้นไม้หรือการเติมข้อความอัตโนมัติ นี่คือเวลาที่ฉันจะส่ง JSON เนื่องจากเป็นข้อมูลที่จะถูกแยกวิเคราะห์และใช้งานดิบ อย่างไรก็ตามถ้าเพียงแค่คุณจะแสดง HTML แล้วมันทำงานได้น้อยกว่ามากในการสร้างฝั่งเซิร์ฟเวอร์และแสดงบนเบราว์เซอร์ เบราว์เซอร์ได้รับการปรับให้เหมาะสมสำหรับการแทรก HTML ลงใน dom โดยตรงด้วย innerHTML = "" ดังนั้นคุณจะไม่ผิดพลาด

ฉันคิดว่ามันขึ้นอยู่กับโครงสร้างของการออกแบบมันแค่เซ็กซี่กว่าที่จะใช้ JSON มากกว่า HTML แต่คำถามก็คือจะมีวิธีจัดการกับมันอย่างไรเพื่อให้สามารถดูแลรักษาได้ง่าย

ตัวอย่างเช่นสมมติว่าฉันมีหน้ารายการที่ใช้ html / style เหมือนกันทั้งไซต์ฉันจะเขียนฟังก์ชันส่วนกลางเพื่อจัดรูปแบบส่วนเหล่านั้นของ HTML และสิ่งที่ฉันต้องทำคือส่งวัตถุ JSON ไปยังฟังก์ชัน

การตอบสนอง HTML นั้นเพียงพอในกรณีส่วนใหญ่เว้นแต่ว่าคุณจะต้องทำการคำนวณบางอย่างที่ฝั่งไคลเอ็นต์

ขึ้นอยู่กับสถานการณ์

บางครั้งจำเป็นต้องหลีกเลี่ยง JSON เมื่อโปรแกรมเมอร์ของเราประสบปัญหาในการเขียนโปรแกรมใน js เป็นต้น

ประสบการณ์ของฉันบอกฉันว่า: ใช้ ajax service ได้ดีกว่า inline JSON

ไม่ช้าก็เร็ว js จะกลายเป็นปัญหา