응답.쓰기 대 <%= %>

Question

이는 다음을 위한 것임을 명심하세요. 클래식 ASP

Response.Write 문에 모든 HTML이 포함되거나 <%= %>를 통해 HTML에 변수를 삽입하는 것이 더 좋습니다.
예:

Response.Write "<table>" & vbCrlf
Response.Write "<tr>" &vbCrLf
Response.Write "<td class=""someClass"">" & someVariable & "</td>" & vbCrLf
Response.Write "</tr>" & vbCrLf
Response.Write "</table>" & vbCrLf

VS

<table>
  <tr>
     <td class="someClass"><%= someVariable %></td>
  </tr>
</table>

나는 주로 삽입할 변수가 여러 개 있을 때 서버에 가장 적은 영향을 미치는 성능 관점에서 묻고 있습니다.

기술적 차이가 없다면 서로에 대한 주장은 무엇입니까?

Answer 1

첫째, 가장 중요한 요소는 유지 보수의 용이성입니다. 돈과 시간이있는 서버 농장을 구입하여 지저분한 웹 사이트를 해독하여 유지해야합니다.

어쨌든 그것은 중요하지 않습니다. 하루가 끝나면 ASP는 스크립트를 실행하는 것입니다! ASP 파서가 페이지를 가져 와서 변환합니다 <%= expression %> 직접 스크립트 호출로, 모든 인접한 HTML 블록은 하나의 거대한 호출이됩니다. Response.Write. 결과 스크립트는 디스크의 페이지가 변경되지 않으면 캐시 된 스크립트를 다시 계산하지 않으면 캐시 및 재사용입니다.

이제 너무 많이 사용합니다 <%= %> 현대 버전의 "스파게티 코드": 끔찍한 "태그 수프"로 연결됩니다. 논리의 머리 나 꼬리를 만들 수는 없습니다. 다른 한편으로, 너무 많은 응답을 사용하면 렌더링 될 때까지 페이지를 전혀 볼 수 없다는 것을 의미합니다. 사용 <%= %> 두 세계를 최대한 활용하기에 적합한 경우.

나의 첫 번째 규칙은 "정적 텍스트"에서 "변수 텍스트"의 비율로주의를 기울이는 것입니다.

교체 할 변수 텍스트가있는 장소가 몇 개있는 경우 <%= %> 구문은 매우 작고 읽을 수 있습니다. 그러나 <%= %> 축적되기 시작하고, 그들은 점점 더 많은 HTML을 가리고 동시에 HTML이 점점 더 많은 논리를 모호하게합니다. 일반적으로 루프에 대해 복용하기 시작하면 중지하고 response.write로 전환해야합니다.

다른 단단하고 빠른 규칙은 많지 않습니다. 특정 페이지 (또는 페이지의 섹션)를 결정 해야하는 것이 더 중요하거나 이해하기 어려운 자연스럽게 이해하기가 더 어려운지, 즉 논리 또는 HTML? 그것은 보통 하나 또는 다른 것입니다 (나는 둘 다 수백 건의 사례를 보았습니다)

논리가 더 중요하다면 더 많은 무게가 Response.Write; 논리가 눈에 띄게됩니다. HTML이 더 중요하다면 호의적입니다 <%= %>, 페이지 구조를보다 눈에 띄게 만듭니다.

때로는 두 버전을 모두 작성하고 나란히 비교하여 어떤 것이 더 읽을 수 있는지 결정해야했습니다. 그것은 최후의 수단이지만, 코드가 당신의 마음에 신선한 상태에서 3 개월 후에 당신은 변경해야 할 때 기뻐할 것입니다.

Answer 2

개인 선호도 관점에서 나는 정적 컨텐츠에서 더 나은 분리 변수 내용을 제공한다고 생각하기 때문에 < %= %> 메소드를 선호합니다.

Answer 3

다른 사람들이 다루었던 코드 판독 가능성/유지성 문제를 제외하고, 귀하의 질문은 삽입 할 여러 변수가있을 때의 성능에 관한 것이 었습니다. 따라서 코드 조각과 같은 것을 여러 번 반복 할 것이라고 가정합니다. 이 경우 단일 응답을 사용하여 최상의 성능을 얻어야합니다. 모든 신약을 연결하지 않고 작성해야합니다.

Response.Write "<table><tr><td class=""someClass"">" & someVar & "</td></tr></table>"

브라우저에는 HTML을 구문 분석하기 위해 최신 또는 탭 또는 기타 예쁜 서식이 필요하지 않습니다. 공연을하려고한다면이 모든 것을 제거 할 수 있습니다. 또한 HTML 출력을 더 작게 만들면 페이지로드 시간이 빠릅니다.

단일 변수의 경우 실제로 많은 차이를 만들지 않습니다. 그러나 여러 변수의 경우 HTML과 ASP 간의 컨텍스트 전환을 최소화하려고합니다. 매번 점프 할 때마다 타격을받을 것입니다.

더 긴 명령문을 구축 할 때 재시험 가능성을 돕기 위해 소스 코드의 VBScript 라인 연속 charcter 및 탭을 사용하여 (출력은 아님)를 사용하여 성능을 누르지 않고 구조를 나타낼 수 있습니다.

Response.Write "<table>" _
        & "<tr>" _
            & "<td class=""someClass"">" & someVar & "</td>" _
        & "</tr>" _
        & "<tr>" _
            & "<td class=""anotherClass"">" & anotherVar & "</td>" _
        & "</tr>" _
        & "<tr>" _
            & "<td class=""etc"">" & andSoOn & "</td>" _
        & "</tr>" _
    & "</table>"

HTML 버전만큼 읽을 수는 없지만 출력에 많은 변수를 삭제하는 경우 (즉, HTML과 ASP 사이의 많은 컨텍스트 전환) 성능이 향상됩니다.

성능 향상이 가치가 있는지 또는 하드웨어를 확장하는 것이 더 나을 지 여부는 별도의 질문이며 물론 항상 옵션은 아닙니다.

업데이트: 응답으로 성능 향상 및 컨텍스트 전환을 피하기 위해 Len Cardinal 의이 MSDN 기사의 팁 14 및 15를 참조하십시오. http://msdn.microsoft.com/en-us/library/ms972335.aspx#asptips_topic15.

Answer 4

여기의 많은 답변은 두 가지 접근 방식이 동일한 출력을 생성하고 선택은 코딩 스타일과 성능 중 하나라는 것을 나타냅니다. < % %> 이외의 정적 컨텐츠는 단일 응답이 된 것으로 생각됩니다.

그러나 외부 코드 < % %>가 BinaryWrite와 함께 전송된다고 말하는 것이 더 정확합니다.

response.write는 유니 코드 문자열을 가져 와서 버퍼에 넣기 전에 현재 응답으로 인코딩합니다. ASP 파일의 정적 컨텐츠에 대한 인코딩은 발생하지 않습니다. 외부 < % %>의 문자는 버퍼에 바이트를 위해 구두 바이트로 덤프됩니다.

따라서 응답이 ASP 파일을 저장하는 데 사용 된 코드 페지와 다르면 두 가지 접근 방식의 결과가 다를 수 있습니다.

예를 들어이 컨텐츠가 표준 1252 코드 페이지에 저장되었다고 가정 해 봅시다.

<%
     Response.CodePage = 65001
     Response.CharSet = "UTF-8"
 %>
<p> The British £</p>
<%Response.Write("<p> The British £</p>")%>

£는 UTF-8 인코딩을 사용하여 전송되지 않기 때문에 첫 번째 단락은 차별화됩니다. 두 번째 단락은 UTF-8로 인코딩되기 때문에 괜찮습니다.

따라서 정적 컨텐츠를 사용하는 성능의 관점에서 인코딩이 필요하지 않지만 저장된 코드 페이지가 출력 코드와 다른 경우 관리가 필요하기 때문에 바람직합니다. 이러한 이유로 UTF-8으로 저장하는 것을 선호하고 <%@ codepage = 65001을 포함하고 set response.charset = "utf-8"을 포함합니다.

Answer 5

나는 여러 가지 이유로 대부분의 상황에서 <%= %> 방법을 선호합니다.

1. HTML은 IDE에 노출되어 툴팁, 태그 닫기 등을 제공 할 수 있도록 처리 할 수 ​​있습니다.
2. 출력 HTML의 인기를 유지하는 것이 더 쉬워서 재 작업 레이아웃에 매우 도움이 될 수 있습니다.
3. 출력 소스를 검토하기 위해 VBCRLF를 모든 것에 추가하지 않은 새로운 라인.

Answer 6

응답 형식은 HTML을 그렇게 렌더링합니다.

<table>
<tr>
<td class="someClass">variable value</td>
</tr>
</table>

결과적으로 코드를 작성하는 수단은 읽을 수 없을뿐만 아니라 결과는 부적절하게 탭됩니다. 다른 옵션을 고수하십시오.

Answer 7

나는 선호한다 <%= %> JavaScript 개발이 더 쉬워지기 때문입니다. 이와 같은 컨트롤을 참조하는 코드를 작성할 수 있습니다.

var myControl = document.getElementById('<%= myControl.ClientID %>');

그런 다음 하드 코딩 된 ID에 대해 걱정하지 않고 JavaScript 코드에서 원하는 방식으로 제어 할 수 있습니다.

Response.Write는 일부 경우에 일부 ASP.NET AJAX 코드를 중단 할 수 있으므로 사용자 정의 컨트롤에서 특정 사항을 렌더링하는 데 사용하지 않는 한 피하려고합니다.

Answer 8

ASP/PHP를 수행 할 때 MVC 패러다임을 사용하려고합니다. 유지하기가 가장 쉬운 일을 유지하고, 재건하고, 확장합니다. 그런 점에서 모델을 나타내는 페이지가있는 경향이 있습니다. 대부분 VB/PHP이며 나중에보기에서 Vars를 설정합니다. 또한 나중에 뷰에 포함시키기 위해 루핑 할 때 HTML의 덩어리를 생성합니다. 그런 다음보기를 나타내는 페이지가 있습니다. 그것은 주로 < %= %> 태그가있는 HTML입니다. 모델은보기에서 #include -d이며 멀리 떨어져 있습니다. 컨트롤러 로직은 일반적으로 세 번째 페이지 또는 서버 측의 JavaScript에서 수행됩니다.

Answer 9

내 클래식 ASP는 녹슬었지만 :

Response.Write "<table>" & vbCrlf
Response.Write "<tr>" &vbCrLf
Response.Write "<tdclass=""someClass"">" & someVariable & "</td>" & vbCrLf 
Response.Write "</tr>" & vbCrLf 
Response.Write "</table>" & vbCrLf

이것은 as-is입니다. 그러나 이것은 :

<table>
  <tr>
     <td class="someClass"><%= someVariable %></td>
  </tr>
</table>

결과 :

Response.Write"<table>\r\n<tr>\r\n<td class="someClass">"
Response.Write someVariable
Response.Write "</td>\r\n</tr>\r\n</table>"

여기서 r n은 vbcrlf입니다

기술적으로 두 번째는 더 빠릅니다. 그러나 차이는 단일 밀리 초로 측정되므로 걱정하지 않을 것입니다. 나는 두 번째로 유지하기가 사소한 곳인 상위 하나가 거의 인재 할 수 없다는 점에 대해 더 우려하고있다 (HTML-UI 개발자).

@Euro Micelli에 소품 - 유지 보수는 핵심입니다 (이것은 또한 Ruby, Python 및 과거에 (Tho Still ....) C# 및 Java가 C, C ++ 및 Assembly -Humans가 코드를 유지할 수있는 이유이기도합니다. 페이지로드에서 몇ms를 면도하는 것보다 더 중요합니다.

물론 C/C ++ 등에는 자리가 있습니다 ....하지만 그렇지 않습니다. :)

Answer 10

<%= %> 그리고 나머지는 확장됩니다 Response.Write() 결국 동일합니다.

Answer 11

Response.write 로의 성능 향상 전환이 없으며 바로 가기 표기법을 사용하여 읽고 유지하는 것이 더 빠를 수 있습니다.

Answer 12

코드 재사용 및 코드 유지 관리 가능성 (일명 가독성) 측면 에서이 질문을 구성해야합니다. 어느 쪽이든 성능 게인은 없습니다.

Answer 13

<%= bazify ()%> a에서 html을 생성 할 때 유용합니다 일부 HTML과의 짧은 표현 인라인.

응답. "foo"쓰기 당신이 할 필요가있을 때 더 좋습니다 많은 코드가있는 HTML 인라인.

기술적으로 그들은 동일합니다.

그러나 당신의 예에 대해 말하지만, 응답 코드는 &와 함께 많은 문자열을 연결합니다. vbscript에서 매우 느립니다. 또한, 좋아요 러셀 마이어스가 말했다, 그것은 의도하지 않을 수있는 다른 코드와 같은 방식으로 탭되지 않습니다.

Answer 14

나는 동의한다 제이슨, .NET은 이제 그 끔찍한 웹 양식/postback/viewstate .net에 대한 대안으로 MVC 프레임 워크를 제공하고 있습니다.

어쩌면 내가 구식 클래식 ASP/HTML/JavaScript 였고 VB 데스크탑 응용 프로그램 프로그래머가 아니기 때문에 "웹 양식의 길"을 Grokk하지 않게 만들었습니다. 그러나 나는 우리가 완전하게 가고 다음과 같은 방법론으로 돌아가는 것 같아서 너무 기뻐요 제이슨 을 참고하여.

이를 염두에두고, 나는 항상 모델/로직이 포함 된 포함 된 페이지를 선택하고 < %= %> 토큰이 html "보기"를 효과적으로 템플릿합니다. 귀하의 HTML은 더 "읽기 쉬운"것이며 논리는 고전적인 ASP가 허용하는만큼 분리됩니다. 당신은 그 돌로 새 두 마리를 죽이고 있습니다.

Answer 15

클래식 ASP 응용 프로그램을 작성하고 유지 관리 해야하는 경우 무료 Kudzuasp 템플릿 엔진을 확인해야합니다.

100% 코드 및 HTML 분리가 가능하며 원래 ASP 페이지의 조건부 컨텐츠, 가변 대체, 템플릿 레벨 제어를 허용합니다. IF-then-ELSE, Try-Catch Finally, Switch-Case 및 기타 구조 태그는 ASP 페이지 또는 동적으로로드 가능한 라이브러리 (ASP 코드 파일)를 기반으로하는 사용자 정의 태그뿐만 아니라 다른 구조에 포함시킬 수 있습니다. 원하는 수준으로 태그.

사용자 정의 태그 및 태그 라이브러리는 작성하기 쉽고 ASP 페이지의 코드 레벨에 또는 템플릿 레벨의 포함 태그를 사용하여 포함 할 수 있습니다.

마스터 페이지는 마스터 페이지 레벨에서 템플릿 엔진을 호출하고 내부 컨텐츠에 대한 두 번째 하위 템플릿 엔진을 활용하여 작성할 수 있습니다.

Kudzuasp에서 ASP 페이지에는 코드 만 포함되어 있고 템플릿 엔진을 생성하고 초기 조건을 설정하고 템플릿을 호출합니다. 템플릿에는 HTML 레이아웃이 포함되어 있습니다. ASP 페이지가 템플릿을 호출하면 템플릿의 평가와 포함 된 구조에 의해 완전히 구동되는 이벤트 구동 자원이됩니다.