ASP.NET MVC 뷰 엔진 (커뮤니티 위키)
포괄적 인 목록이 존재하지 않는 것으로 보이므로 여기서 시작하십시오. 사람들이 경험을 추가하면 (예 :이 중 하나에 기여한 사람) ASP.NET MVC 커뮤니티에 큰 도움이 될 수 있습니다. 구현하는 것 IViewEngine(예 :) VirtualPathProviderViewEngine은 여기서 공정한 게임입니다. 새로운 View Engine을 알파벳순으로 정렬하고 (WebFormViewEngine 및 Razor를 맨 위에두고) 비교에서 객관적인 자세를 취하십시오.
System.Web.Mvc.WebFormViewEngine
설계 목표 :
Web Forms 페이지를 응답으로 렌더링하는 데 사용되는 뷰 엔진입니다.
장점 :
- ASP.NET MVC와 함께 제공되므로 유비쿼터스
- ASP.NET 개발자에게 친숙한 경험
- IntelliSense
- CodeDom 공급자 (예 : C #, VB.NET, F #, Boo, Nemerle)를 사용하여 모든 언어를 선택할 수 있습니다
- 주문형 컴파일 또는 사전 컴파일 된 뷰
단점 :
- 더 이상 MVC에 적용되지 않는 "클래식 ASP.NET"패턴의 존재로 인해 사용이 혼동됩니다 (예 : ViewState PostBack)
- "태그 수프"의 안티 패턴에 기여할 수 있습니다
- 코드 블록 구문과 강력한 타이핑은 방해가 될 수 있습니다
- IntelliSense는 인라인 코드 블록에 항상 적절한 스타일을 적용하지는 않습니다.
- 간단한 템플릿을 디자인 할 때 시끄러울 수 있습니다
예:
<%@ Control Inherits="System.Web.Mvc.ViewPage<IEnumerable<Product>>" %>
<% if(model.Any()) { %>
<ul>
<% foreach(var p in model){%>
<li><%=p.Name%></li>
<%}%>
</ul>
<%}else{%>
<p>No products available</p>
<%}%>
System.Web.Razor
설계 목표 :
장점 :
- 콤팩트, 표현 및 유체
- 배우기 쉬운
- 새로운 언어가 아닙니다
- 훌륭한 Intellisense가 있습니다
- 테스트 가능한 단위
- 유비쿼터스, ASP.NET MVC와 함께 제공
단점 :
- 위에서 언급 한 "태그 수프"와 약간 다른 문제를 만듭니다. 서버 태그가 실제로 서버 및 비 서버 코드를 중심으로 구조를 제공하는 경우, Razor는 HTML 및 서버 코드를 혼동하여 HTML 및 / 또는 JavaScript를 "탈출"해야 할 때 순수한 HTML 또는 JS 개발에 어려움을 겪습니다 (예제 1 참조). 매우 일반적인 특정 조건에서 태그.
- 열악한 캡슐화 + 재사용 가능성 : 일반적인 방법 인 것처럼 면도기 템플릿을 호출하는 것은 비현실적입니다. 실제로 면도기는 코드를 호출 할 수 있지만 그 반대는 불가능하므로 코드와 프레젠테이션의 혼합을 장려 할 수 있습니다.
- 구문은 매우 HTML 중심입니다. HTML이 아닌 컨텐츠를 생성하는 것은 까다로울 수 있습니다. 그럼에도 불구하고 면도기의 데이터 모델은 본질적으로 문자열 연결이므로 구문 및 중첩 오류는 정적으로 또는 동적으로 감지되지 않지만 VS.NET 디자인 타임은 다소 완화됩니다. 이로 인해 유지 보수성 및 리팩토링 성이 저하 될 수 있습니다.
문서화 된 API 없음 , http://msdn.microsoft.com/en-us/library/system.web.razor.aspx
Con 예 # 1 ( "string [] ..."의 배치에 주목) :
@{
<h3>Team Members</h3> string[] teamMembers = {"Matt", "Joanne", "Robert"};
foreach (var person in teamMembers)
{
<p>@person</p>
}
}
벨뷰
설계 목표 :
- HTML을 "단지 텍스트"로 취급하는 대신 HTML을 일급 언어로 존중하십시오.
- 내 HTML을 망설이지 마십시오! 데이터 바인딩 코드 (Bellevue 코드)는 HTML과 분리되어야합니다.
- 엄격한 Model-View 분리 시행
부레
설계 목표 :
Brail보기 엔진은 MonoRail에서 Microsoft ASP.NET MVC Framework와 함께 작동하도록 포팅되었습니다. Brail에 대한 소개는 Castle 프로젝트 웹 사이트 의 문서를 참조하십시오 .
장점 :
- "손목 친화적 인 파이썬 구문"을 모델링
- 요청시 컴파일 된 뷰 (사용 가능한 사전 컴파일은 없음)
단점 :
예:
<html>
<head>
<title>${title}</title>
</head>
<body>
<p>The following items are in the list:</p>
<ul><%for element in list: output "<li>${element}</li>"%></ul>
<p>I hope that you would like Brail</p>
</body>
</html>
하식
Hasic은 대부분의 다른 뷰 엔진과 같은 문자열 대신 VB.NET의 XML 리터럴을 사용합니다.
장점 :
- 유효한 XML의 컴파일 타임 확인
- 구문 채색
- 완전한 지능
- 컴파일 된 뷰
- 정규 CLR 클래스, 함수 등을 사용한 확장 성
- 일반적인 VB.NET 코드이기 때문에 완벽한 구성 및 조작
- 테스트 가능한 단위
단점 :
- 성능 : 전체 DOM을 클라이언트로 보내기 전에 빌드합니다.
예:
Protected Overrides Function Body() As XElement
Return _
<body>
<h1>Hello, World</h1>
</body>
End Function
NDjango
설계 목표 :
NDjango는 F # 언어를 사용하여 .NET 플랫폼 에서 Django 템플릿 언어 를 구현 한 것입니다
.
장점 :
NHaml
설계 목표 :
Rails Haml보기 엔진의 .NET 포트. 에서 HAML 웹 사이트 :
Haml은 인라인 코드를 사용하지 않고 웹 문서의 XHTML을 깨끗하고 간단하게 설명하는 데 사용되는 마크 업 언어입니다 ... Haml은 XHTML에 대한 추상적 인 설명이므로 XHTML을 템플릿에 명시 적으로 코딩 할 필요가 없습니다. 동적 콘텐츠를 생성하는 코드가 있습니다.
장점 :
단점 :
- 마크 업에 익숙하지 않고 XHTML에서 추출한 것
- VS2010에 대한 Intellisense 없음
예:
@type=IEnumerable<Product>
- if(model.Any())
%ul
- foreach (var p in model)
%li= p.Name
- else
%p No products available
NVelocityViewEngine (MvcContrib)
설계 목표 :
인기있는 Java 프로젝트 Velocity 의 .NET 포트 인 NVelocity 를
기반으로하는 뷰 엔진
입니다.
장점 :
단점 :
- 뷰에서 사용할 수있는 제한된 수의 도우미 메서드
- Visual Studio 통합 (IntelliSense, 뷰의 컴파일 타임 확인 또는 리팩토링)을 자동으로 갖지 않음
예:
#foreach ($p in $viewdata.Model)
#beforeall
<ul>
#each
<li>$p.Name</li>
#afterall
</ul>
#nodata
<p>No products available</p>
#end
SharpTiles
설계 목표 :
SharpTiles는 JSTL 의 일부 포트로서 Tiles 프레임 워크의
개념과 결합되었습니다 ( 마일스톤 1 기준).
장점 :
- Java 개발자에게 친숙
- XML 스타일 코드 블록
단점 :
예:
<c:if test="${not fn:empty(Page.Tiles)}">
<p class="note">
<fmt:message key="page.tilesSupport"/>
</p>
</c:if>
스파크 뷰 엔진
설계 목표 :
아이디어는 HTML이 흐름을 지배하고 코드가 완벽하게 맞도록하는 것입니다.
장점 :
단점 :
- 리터럴 마크 업에서 템플릿 로직을 명확하게 분리하지 않음 (네임 스페이스 접두사로 완화 할 수 있음)
예:
<viewdata products="IEnumerable[[Product]]"/>
<ul if="products.Any()">
<li each="var p in products">${p.Name}</li>
</ul>
<else>
<p>No products available</p>
</else>
<Form style="background-color:olive;">
<Label For="username" />
<TextBox For="username" />
<ValidationMessage For="username" Message="Please type a valid username." />
</Form>
StringTemplate View Engine MVC
설계 목표 :
- 경량. 페이지 클래스가 작성되지 않았습니다.
- 빠른. 템플리트가 응답 출력 스트림에 작성됩니다.
- 캐시되었습니다. 템플릿은 캐시되지만 FileSystemWatcher를 사용하여 파일 변경을 감지합니다.
- 동적. 코드에서 템플릿을 즉석에서 생성 할 수 있습니다.
- 융통성 있는. 템플릿은 모든 레벨에 중첩 될 수 있습니다.
- MVC 원칙에 따라. UI와 비즈니스 로직의 분리를 촉진합니다. 모든 데이터는 미리 생성되어 템플릿으로 전달됩니다.
장점 :
- StringTemplate Java 개발자에게 친숙
단점 :
- 단순한 템플릿 구문은 의도 된 출력을 방해 할 수 있습니다 (예 : jQuery 충돌 )
윙 비트
Wing Beats는 XHTML을 만들기위한 내부 DSL입니다. F #을 기반으로하며 ASP.NET MVC 뷰 엔진을 포함하지만 XHTML을 만드는 기능에만 사용될 수 있습니다.
장점 :
- 유효한 XML의 컴파일 타임 확인
- 구문 채색
- 완전한 지능
- 컴파일 된 뷰
- 정규 CLR 클래스, 함수 등을 사용한 확장 성
- 일반적인 F # 코드이기 때문에 완벽한 구성 및 조작
- 테스트 가능한 단위
단점 :
- 실제로 HTML을 작성하지는 않지만 DSL에서 HTML을 나타내는 코드를 작성합니다.
XsltViewEngine (MvcContrib)
설계 목표 :
익숙한 XSLT에서 뷰를 작성합니다.
장점 :
- 널리 유비쿼터스
- XML 개발자를위한 친숙한 템플릿 언어
- XML 기반
- 시간 테스트
- 구문 및 요소 중첩 오류를 정적으로 감지 할 수 있습니다.
단점 :
- 기능적 언어 스타일은 흐름 제어를 어렵게 만듭니다.
- XSLT 2.0은 지원되지 않습니다. (XSLT 1.0은 훨씬 실용적이지 않습니다).