Tại sao việc trả lại HTML được tạo thay vì JSON là một cách thực hành tồi? Hoặc là nó?

Việc tải nội dung HTML từ các dịch vụ web / URL tùy chỉnh của bạn bằng JQuery hoặc bất kỳ khung tương tự nào khác khá dễ dàng. Tôi đã sử dụng phương pháp này nhiều lần và cho đến bây giờ và thấy hiệu suất đạt yêu cầu.

Nhưng tất cả các cuốn sách, tất cả các chuyên gia đang cố gắng để tôi sử dụng JSON thay vì HTML được tạo. Làm thế nào nó vượt trội hơn nhiều so với HTML?

Nó có nhanh hơn nhiều không?
Liệu nó có tải rất ít trên máy chủ?

Mặt khác, tôi có một số lý do để sử dụng HTML được tạo.

1. Đó là cách đánh dấu đơn giản và thường nhỏ gọn hoặc thực sự nhỏ gọn hơn JSON.
2. Nó ít bị lỗi hơn vì tất cả những gì bạn nhận được là đánh dấu và không có mã.
3. Nó sẽ nhanh hơn để lập trình trong hầu hết các trường hợp vì bạn sẽ không phải viết mã riêng cho phần cuối của máy khách.

Bạn ở bên nào và tại sao?

Tôi thực sự là một chút ở cả hai phía:

• Khi những gì tôi cần ở phía javascript là dữ liệu , tôi sử dụng JSON
• Khi những gì tôi cần ở phía javascript là phần trình bày mà tôi sẽ không thực hiện bất kỳ phép tính nào, tôi thường sử dụng HTML

Ưu điểm chính của việc sử dụng HTML là khi bạn muốn thay thế một phần đầy đủ của trang của mình bằng những gì quay lại từ yêu cầu Ajax:

• Xây dựng lại một phần trang trong JS là (khá) khó
• Bạn có thể đã có một số công cụ tạo khuôn mẫu ở phía máy chủ, được sử dụng để tạo trang ở vị trí đầu tiên ... Tại sao không sử dụng lại nó?

Tôi thường không thực sự xem xét khía cạnh "hiệu suất" của mọi thứ, ít nhất là trên máy chủ:

• Trên máy chủ, việc tạo một phần HTML hoặc một số JSON có thể sẽ không tạo ra nhiều sự khác biệt
• Về kích thước của nội dung qua mạng: tốt, bạn có thể không sử dụng hàng trăm KB dữ liệu / html ... Sử dụng gzip trên bất cứ thứ gì bạn đang chuyển là điều sẽ tạo ra sự khác biệt lớn nhất (không chọn giữa HTML và JSON)
• Tuy nhiên, một điều có thể được xem xét là tài nguyên mà bạn cần trên máy khách để tạo lại HTML (hoặc cấu trúc DOM) từ dữ liệu JSON ... so sánh với việc đẩy một phần HTML vào trang; -)

Cuối cùng, một điều chắc chắn có vấn đề:

• Bạn sẽ mất bao lâu để phát triển một hệ thống mới sẽ gửi dữ liệu dưới dạng mã JSON + mà JS yêu cầu để đưa nó dưới dạng HTML vào trang?
• Sẽ mất bao lâu để trả về HTML? Và mất bao lâu nếu bạn có thể sử dụng lại một số mã phía máy chủ hiện có của mình?

Và để trả lời một câu trả lời khác: nếu bạn cần cập nhật nhiều hơn một phần của trang, vẫn có giải pháp / hack gửi tất cả các phần đó trong một chuỗi lớn nhóm một số phần HTML và trích xuất các phần có liên quan trong JS.

Chẳng hạn, bạn có thể trả về một số chuỗi trông như thế này:

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

Điều đó trông không thực sự tốt, nhưng nó thực sự hữu ích (tôi đã sử dụng nó khá nhiều lần, chủ yếu là khi dữ liệu HTML quá lớn để được gói gọn trong JSON) : bạn đang gửi HTML cho các phần của trang cần trình bày và bạn đang gửi JSON cho tình huống bạn cần dữ liệu ...

... Và để giải nén chúng, phương thức chuỗi con JS sẽ thực hiện thủ thuật, tôi cho rằng ;-)

Tôi chủ yếu đồng ý với các ý kiến ​​nêu ở đây. Tôi chỉ muốn tóm tắt chúng là:

• Việc gửi HTML là một thực tế tồi nếu bạn kết thúc việc phân tích cú pháp phía máy khách để thực hiện một số tính toán đối với nó.

• Việc gửi JSON là một thực tế tồi nếu tất cả những gì bạn sẽ làm là kết hợp nó vào cây DOM của trang.

Tốt,

Tôi là một trong những người hiếm hoi thích phân tách mọi thứ theo cách này: - Máy chủ chịu trách nhiệm phân phối dữ liệu (kiểu máy); - Máy khách có trách nhiệm hiển thị (xem) và thao tác dữ liệu (mô hình);

Vì vậy, máy chủ nên tập trung vào việc phân phối mô hình (trong trường hợp này là JSON tốt hơn). Bằng cách này, bạn có được một cách tiếp cận linh hoạt. Nếu bạn muốn thay đổi chế độ xem mô hình của mình, bạn giữ máy chủ gửi cùng một dữ liệu và chỉ thay đổi ứng dụng khách, các thành phần javascript, thay đổi dữ liệu đó thành dạng xem. Hãy tưởng tượng, bạn có một máy chủ cung cấp dữ liệu cho các thiết bị di động cũng như các ứng dụng trên máy tính để bàn.

Ngoài ra, cách tiếp cận này làm tăng năng suất, vì mã máy chủ và máy khách có thể được xây dựng cùng một lúc, không bao giờ mất trọng tâm, điều sẽ xảy ra khi bạn tiếp tục chuyển từ js sang PHP / JAVA / v.v.

Nói chung, tôi nghĩ rằng hầu hết mọi người thích làm nhiều nhất có thể ở phía máy chủ vì họ không thành thạo js, ​​vì vậy họ cố gắng tránh nó càng nhiều càng tốt.

Về cơ bản, tôi có cùng quan điểm với những kẻ đang làm việc trên Angular. Theo tôi đó là tương lai của các ứng dụng web.

Tôi có một cái gì đó thú vị tôi nghĩ rằng tôi có thể thêm. Tôi đã phát triển một ứng dụng chỉ tải toàn bộ một lần xem. Từ thời điểm đó trở đi, nó chỉ liên lạc trở lại máy chủ với ajax. Nó chỉ cần tải một trang (lý do của tôi cho việc này là không quan trọng ở đây). Phần thú vị là tôi có một nhu cầu đặc biệt để trả về một số dữ liệu sẽ được vận hành trong javascript VÀ một phần xem được hiển thị. Tôi có thể chia nó thành hai cuộc gọi thành hai phương thức hành động riêng biệt nhưng tôi quyết định thực hiện một điều gì đó thú vị hơn một chút.

Kiểm tra xem nó:

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

RenderPartialViewToString () bạn có thể hỏi là gì? Đây là một chút mát mẻ ngay tại đây:

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

Tôi chưa thực hiện bất kỳ thử nghiệm hiệu năng nào về vấn đề này vì vậy tôi không chắc liệu nó có phát sinh nhiều hơn hoặc ít hơn so với việc gọi một phương thức hành động cho JsonResult và một cho ParticalViewResult hay không, nhưng tôi vẫn nghĩ nó khá tuyệt. Nó chỉ tuần tự hóa một khung nhìn một phần thành một chuỗi và gửi nó cùng với Json như một trong các tham số của nó. Sau đó tôi sử dụng JQuery để lấy tham số đó và đưa nó vào nút DOM thích hợp :)

Hãy cho tôi biết những gì bạn nghĩ về hybrid của tôi!

Nếu phản hồi không cần xử lý phía khách hàng nữa, theo ý kiến ​​của tôi thì HTML vẫn ổn. Gửi JSON sẽ chỉ buộc bạn thực hiện xử lý phía máy khách đó.

Mặt khác, tôi sử dụng JSON khi tôi không muốn sử dụng tất cả dữ liệu phản hồi cùng một lúc. Ví dụ: tôi có một loạt ba lựa chọn chuỗi, trong đó giá trị được chọn của một xác định giá trị nào sẽ được sử dụng để điền vào thứ hai, v.v.

IMV, đó là tất cả về việc tách dữ liệu khỏi việc trình bày dữ liệu, nhưng tôi với Pascal, không nhất thiết phải tuân theo sự phân tách đó chỉ có thể vượt qua ranh giới máy khách / máy chủ. Nếu bạn đã có sự phân tách đó (trên máy chủ) và chỉ muốn hiển thị một cái gì đó cho khách hàng, cho dù bạn gửi lại JSON và xử lý hậu kỳ trên máy khách hay chỉ gửi lại HTML, hoàn toàn phụ thuộc vào nhu cầu của bạn. Có thể nói bạn "sai" khi gửi lại HTML trong trường hợp chung chỉ là một tuyên bố IMV quá xa vời.

JSON là định dạng rất linh hoạt và nhẹ. Tôi đã phát hiện ra vẻ đẹp của nó khi tôi bắt đầu sử dụng nó làm dữ liệu trình phân tích cú pháp mẫu phía máy khách. Hãy để tôi giải thích, trong khi trước khi tôi sử dụng smarty và các khung nhìn ở phía máy chủ (tạo tải máy chủ cao), bây giờ tôi sử dụng một số hàm jquery tùy chỉnh và tất cả dữ liệu được hiển thị ở phía máy khách, sử dụng trình duyệt máy khách làm trình phân tích cú pháp mẫu. nó lưu các máy chủ lưu trữ và trên một trình duyệt khác cải thiện công cụ JS của họ mỗi ngày. Vì vậy, tốc độ phân tích cú pháp của khách hàng không phải là một vấn đề quan trọng ngay bây giờ, thậm chí nhiều hơn, các đối tượng JSON rất nhỏ để chúng không tiêu tốn nhiều thông tin từ phía khách hàng. Tôi thích có một trang web chậm cho một số người dùng có trình duyệt chậm hơn là trang web chậm cho tất cả mọi người vì máy chủ rất tải.

Mặt khác, gửi dữ liệu thuần túy từ máy chủ, bạn trừu tượng hóa nó khỏi bản trình bày, vì vậy nếu ngày mai bạn muốn thay đổi hoặc tích hợp dữ liệu của mình vào một dịch vụ khác, bạn có thể thực hiện việc đó dễ dàng hơn nhiều.

Chỉ 2 xu của tôi.

Nếu bạn muốn một ứng dụng khách tách rời, theo ý kiến ​​của tôi là cách thực hành tốt nhất, thì có nghĩa là có 100% DOM được tạo bởi javascript. Nếu bạn xây dựng một ứng dụng khách dựa trên MVC có tất cả các cách biết để xây dựng giao diện người dùng thì người dùng của bạn sẽ tải xuống một tệp javascript một lần và nó được lưu trong bộ nhớ cache trên máy khách. Tất cả các yêu cầu sau tải ban đầu đó đều dựa trên Ajax và chỉ trả về dữ liệu. Cách tiếp cận này là sạch nhất tôi đã tìm thấy và cung cấp cho một đóng gói độc lập sạch của bài thuyết trình.

Phía máy chủ sau đó chỉ tập trung vào việc cung cấp dữ liệu.

Vì vậy, ngày mai khi sản phẩm yêu cầu bạn thay đổi hoàn toàn thiết kế của một trang, tất cả những gì bạn thay đổi là mã nguồn tạo ra DOM, nhưng có khả năng sử dụng lại các trình xử lý sự kiện đã có của bạn và máy chủ không biết gì vì nó bị tách rời 100% từ bản trình bày

Tùy thuộc vào giao diện người dùng của bạn, bạn có thể cần cập nhật hai (hoặc nhiều) yếu tố khác nhau trong DOM. Nếu câu trả lời của bạn bằng HTML, bạn sẽ phân tích điều đó để tìm ra điều gì sẽ xảy ra ở đâu? Hoặc bạn chỉ có thể sử dụng hàm băm JSON.

Bạn thậm chí có thể kết hợp nó, trả về dữ liệu w / html JSON :)

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

HTML có nhiều dữ liệu dư thừa và không được hiển thị, ví dụ như thẻ, biểu định kiểu, v.v. Vì vậy, kích thước HTML so với dữ liệu JSON sẽ lớn hơn dẫn đến thời gian tải xuống nhiều hơn và thời gian kết xuất cũng sẽ khiến trình duyệt bận rộn hiển thị dữ liệu mới.

Gửi json thường được thực hiện khi bạn có tiện ích javascript yêu cầu thông tin từ máy chủ, chẳng hạn như danh sách hoặc chế độ xem dạng cây hoặc tự động hoàn tất. Đây là khi tôi gửi JSON vì đây là dữ liệu sẽ được phân tích cú pháp và sử dụng thô. Tuy nhiên, nếu bạn chỉ hiển thị HTML thì việc tạo phía máy chủ sẽ ít hơn và chỉ hiển thị trên trình duyệt. Các trình duyệt được tối ưu hóa để chèn HTML trực tiếp vào dom với InternalHTML = "" vì vậy bạn không thể sai với điều đó.

Tôi nghĩ nó phụ thuộc vào cấu trúc của thiết kế, việc sử dụng JSON sẽ hấp dẫn hơn HTML nhưng câu hỏi đặt ra là làm thế nào để người ta xử lý nó để có thể dễ dàng duy trì.

Ví dụ: giả sử tôi có trang danh sách sử dụng cùng một kiểu html / của toàn bộ trang, tôi sẽ viết hàm toàn cục để định dạng các phần HTML đó và tất cả những gì tôi phải làm là chuyển đối tượng JSON vào hàm.

Phản hồi Html là đủ trong hầu hết các trường hợp trừ khi bạn phải thực hiện một số tính toán ở phía máy khách.

Phụ thuộc vào hoàn cảnh.

Đôi khi nó là điều cần thiết để tránh JSON. Khi lập trình viên của chúng tôi gặp sự cố lập trình trong js chẳng hạn.

Kinh nghiệm của tôi cho tôi biết rằng: sử dụng dịch vụ ajax tốt hơn JSON nội tuyến.

Sớm muộn gì js cũng trở thành vấn đề