JSON 대신 생성 된 HTML을 반환하는 것이 왜 나쁜 습관입니까? 아니면?

JQuery 또는 다른 유사한 프레임 워크를 사용하여 사용자 정의 URL / 웹 서비스에서 HTML 컨텐츠를로드하는 것은 매우 쉽습니다. 나는이 접근법을 여러 번 사용하여 지금까지 성능이 만족 스럽습니다.

그러나 모든 책, 모든 전문가는 생성 된 HTML 대신 JSON을 사용하도록 노력하고 있습니다. HTML보다 훨씬 우수합니까?

훨씬 더 빠릅니까?
서버에 훨씬 적은 부하가 있습니까?

다른 한편으로는 생성 된 HTML을 사용해야하는 몇 가지 이유가 있습니다.

1. 간단한 마크 업이며 종종 JSON보다 콤팩트하거나 실제로 더 콤팩트합니다.
2. 오류가 발생하기 쉽기 때문에 코드가 표시되지 않고 코드가 표시됩니다.
3. 대부분의 경우 프로그래밍하는 것이 더 빠를 것이므로 클라이언트 측에 대해 별도로 코드를 작성할 필요가 없습니다.

어느쪽에 있고 왜?

나는 실제로 양쪽에 조금 있습니다.

• 자바 스크립트 측면에서 필요한 것이 data 일 때 JSON을 사용합니다.
• 자바 스크립트 측면에서 필요한 것이 계산을하지 않을 프레젠테이션 일 때 일반적으로 HTML을 사용합니다.

HTML 사용의 주요 장점은 페이지의 전체 부분을 Ajax 요청에서 나온 내용으로 바꾸려는 경우입니다.

• JS에서 페이지의 일부를 다시 작성하는 것은 어렵습니다.
• 서버쪽에 이미 템플릿 엔진이있을 수 있습니다.이 엔진은 처음에 페이지를 생성하는 데 사용되었습니다. 왜 재사용하지 않습니까?

나는 일반적으로 서버에서 최소한 "성능"측면을 고려하지 않습니다.

• 서버에서 HTML의 일부 또는 일부 JSON을 생성해도 큰 차이는 없습니다.
• 네트워크를 통과하는 물건의 크기에 관해서 : 글쎄, 아마도 수백 KB의 데이터 / HTML을 사용하지 않을 것입니다 ... 전송하는 모든 것에 gzip을 사용하는 것이 가장 큰 차이를 만드는 것입니다 (HTML 중에서 선택하지 않음) 그리고 JSON)
• 그러나 고려해야 할 한 가지는 JSON 데이터에서 HTML (또는 DOM 구조) 을 재생성하기 위해 클라이언트에 필요한 리소스 입니다. HTML의 일부를 페이지로 푸시하는 것과 비교하십시오. -)

마지막으로 중요한 것은 :

• JS를 페이지에 HTML로 삽입하는 데 필요한 JS를 코드로 JSON + 코드로 전송하는 새로운 시스템을 개발하는 데 얼마나 걸립니까?
• 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을 구문 분석하여 계산을 수행하는 경우 HTML을 보내는 것은 좋지 않습니다.

• 결국 JSON을 페이지의 DOM 트리에 통합하기 만하면 JSON을 보내는 것은 좋지 않습니다.

잘,

나는 이런 식으로 물건을 분리하는 것을 좋아하는 드문 사람 중 하나입니다.-서버는 데이터 (모델)를 제공합니다. -고객은 데이터 표시 (보기) 및 조작 (모델)을 담당합니다.

따라서 서버는 모델 제공에 중점을 두어야합니다 (이 경우 JSON이 더 좋습니다). 이렇게하면 유연한 접근 방식을 얻을 수 있습니다. 모델의 뷰를 변경하려면 서버가 동일한 데이터를 전송하고 해당 데이터를 뷰로 변경하는 클라이언트 인 JavaScript 구성 요소 만 변경하면됩니다. 데스크톱 응용 프로그램뿐만 아니라 모바일 장치에 데이터를 전달하는 서버가 있다고 가정하십시오.

또한 서버와 클라이언트 코드를 동시에 구축 할 수있어 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, 그것은 데이터의 표현에서 데이터를 분리하는 것에 관한 것이지만, 파스칼을 사용하고 있습니다. 분리가 클라이언트 / 서버 경계를 넘어서야 만 가능하다는 것을 반드시 따르는 것은 아닙니다. 서버에서 분리가 이미 있고 클라이언트에게 무언가를 보여주고 싶다면 JSON을 다시 보내 클라이언트에서 후 처리하든 HTML을 다시 보내든 관계없이 전적으로 요구 사항에 달려 있습니다. 일반적인 경우에 HTML을 돌려 보내는 것이 "잘못되었다"고 말하는 것은 IMV 문장보다 훨씬 위대하다.

JSON은 매우 다양하고 가벼운 형식입니다. 클라이언트 측 템플릿 파서 데이터로 사용하기 시작했을 때의 아름다움을 발견했습니다. 서버 측에서 smarty 및 뷰를 사용하기 전에 (높은 서버로드 생성) 이제 일부 사용자 정의 jquery 함수를 사용하고 클라이언트 브라우저를 템플릿 파서로 사용하여 모든 데이터가 클라이언트 측에서 렌더링됩니다. 서버 자원을 절약하고 브라우저는 매일 JS 엔진을 개선합니다. 따라서 클라이언트 파싱 속도는 현재 중요한 문제가 아니며, 훨씬 더 많은 JSON 객체는 일반적으로 매우 작기 때문에 많은 클라이언트 측 리소스를 소비하지 않습니다. 나는 매우로드 된 서버로 인해 모두에게 느린 사이트보다는 느린 브라우저를 가진 일부 사용자에게는 느린 웹 사이트를 선호합니다.

한편, 서버에서 순수한 데이터를 전송하면 프리젠 테이션에서 추상화하므로 내일 데이터를 변경하거나 다른 서비스에 데이터를 통합하려는 경우 훨씬 쉽게 수행 할 수 있습니다.

그냥 내 2 센트.

내 의견으로는 모범 사례 인 깨끗한 분리 된 클라이언트를 원한다면 DOM으로 100 % 자바 스크립트로 만든 것이 좋습니다. UI를 빌드하는 방법을 모두 알고있는 MVC 기반 클라이언트를 빌드하는 경우 사용자는 한 번의 Javascript 파일을 다운로드하여 클라이언트에 캐시합니다. 초기로드 이후의 모든 요청은 Ajax 기반이며 데이터 만 반환합니다. 이 접근 방식은 내가 찾은 가장 깨끗하며 프레젠테이션을 독립적으로 깔끔하게 캡슐화합니다.

그런 다음 서버 측은 데이터 전달에 중점을 둡니다.

따라서 내일 제품에서 페이지 디자인을 완전히 변경하도록 요청하면 DOM을 생성하는 소스 JS 만 변경되지만 이미 존재하는 이벤트 핸들러를 재사용 할 수 있으며 서버는 프리젠 테이션에서 100 % 분리 되었기 때문에 서버가 보이지 않습니다

UI에 따라 DOM에서 두 개 이상의 다른 요소를 업데이트해야 할 수도 있습니다. 응답이 HTML로되어 있다면 어디로 가는지 알아 내기 위해 파싱 하시겠습니까? 또는 JSON 해시를 사용할 수 있습니다.

당신은 그것을 결합하고 html 데이터로 JSON을 반환 할 수 있습니다 :)

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

HTML에는 중복 및 표시되지 않은 데이터 (예 : 태그, 스타일 시트 등)가 많이 있습니다. 따라서 JSON 데이터에 비해 HTML 크기가 더 커져 다운로드 및 렌더링 시간이 늘어나고 브라우저가 새 데이터를 렌더링하는 데 바쁠 수 있습니다.

json 보내기는 일반적으로 서버에서 정보를 요청하는 목록, 트리 뷰 또는 자동 완성과 같은 자바 스크립트 위젯이있을 때 수행됩니다. 이것은 파싱되어 원시로 사용될 데이터이므로 JSON을 보낼 때입니다. 그러나 HTML을 표시하려는 경우 HTML을 서버 측에서 생성하고 브라우저에 표시하는 작업이 훨씬 적습니다. 브라우저는 innerHTML = ""을 사용하여 HTML을 DOM에 직접 삽입하도록 최적화되어 있으므로 잘못 사용할 수 없습니다.

디자인의 구조에 달려 있다고 생각합니다 .JSON을 HTML보다 사용하는 것이 더 섹시하지만 문제는 쉽게 처리 할 수 ​​있으므로 유지 관리가 쉽습니다.

예를 들어 전체 사이트의 동일한 HTML / 스타일을 사용하는 목록 페이지가 있다고 가정하면 HTML의 해당 부분을 형식화하기 위해 전역 함수를 작성하고 JSON 객체를 함수에 전달하기 만하면됩니다.

클라이언트 측에서 약간의 계산을 수행하지 않으면 대부분의 경우 HTML 응답으로 충분합니다.

상황에 따라 다릅니다.

때로는 JSON을 피해야합니다. 예를 들어 프로그래머가 js에서 프로그래밍하는 데 문제가있는 경우

내 경험에 따르면 인라인 JSON보다 ajax 서비스를 더 잘 사용합니다.

조만간 js가 문제가됩니다.