나는 SO.Google에서 ASP.NET MVC에 사용할 수있는 다양한 View Engine에 대한 분석을 검색했지만 뷰 엔진이 무엇인지에 대한 간단한 고급 설명 이상을 찾지 못했습니다.
필자는 반드시 “최고”또는 “가장 빠른”을 찾는 것이 아니라 다양한 상황에서 주요 플레이어 (예 : 기본 WebFormViewEngine, MvcContrib View Engine 등)의 장단점에 대한 실제 비교를 찾고 있습니다. 기본 엔진에서 전환하는 것이 주어진 프로젝트 또는 개발 그룹에 유리한지 여부를 결정하는 데 실제로 도움이 될 것이라고 생각합니다.
누구든지 그런 비교를 경험 했습니까?
답변
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>
<%}%>
설계 목표 :
장점 :
- 콤팩트, 표현 및 유체
- 배우기 쉬운
- 새로운 언어가 아닙니다
- 훌륭한 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 프로젝트 웹 사이트 의 문서를 참조하십시오 .
장점 :
- “손목 친화적 인 파이썬 구문”을 모델링
- 요청시 컴파일 된 뷰 (사용 가능한 사전 컴파일은 없음)
단점 :
- 언어 Boo 로 작성되도록 설계
예:
<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는 F # 언어를 사용하여 .NET 플랫폼 에서 Django 템플릿 언어 를 구현 한 것입니다
.
장점 :
- NDjango 릴리스 0.9.1.0은 스트레스 하에서보다 안정적 인 것으로 보입니다.
WebFormViewEngine
- 구문 색상 지정, 코드 완성 및 사용자 진단 기능을 갖춘 Django 템플릿 편집기 (VS2010 만 해당)
- ASP.NET, Castle MonoRail 및 Bistro MVC 프레임 워크와 통합
설계 목표 :
Rails Haml보기 엔진의 .NET 포트. 에서 HAML 웹 사이트 :
Haml은 인라인 코드를 사용하지 않고 웹 문서의 XHTML을 깨끗하고 간단하게 설명하는 데 사용되는 마크 업 언어입니다 … Haml은 XHTML에 대한 추상적 인 설명이므로 XHTML을 템플릿에 명시 적으로 코딩 할 필요가 없습니다. 동적 콘텐츠를 생성하는 코드가 있습니다.
장점 :
- 간결한 구조 (즉, DRY)
- 잘 들여 쓰기
- 명확한 구조
- C # Intellisense (ReSharper가없는 VS2008의 경우)
단점 :
- 마크 업에 익숙하지 않고 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는 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이 흐름을 지배하고 코드가 완벽하게 맞도록하는 것입니다.
장점 :
- 더 읽기 쉬운 템플릿 생성
- C # Intellisense (ReSharper가없는 VS2008의 경우)
- VS2010 용 SparkSense 플러그인 (ReSharper와 함께 작동)
- 뷰에서 모든 코드를 제거 하는 강력한 바인딩 기능 을 제공하고 고유 한 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을 나타내는 코드를 작성합니다.
설계 목표 :
익숙한 XSLT에서 뷰를 작성합니다.
장점 :
- 널리 유비쿼터스
- XML 개발자를위한 친숙한 템플릿 언어
- XML 기반
- 시간 테스트
- 구문 및 요소 중첩 오류를 정적으로 감지 할 수 있습니다.
단점 :
- 기능적 언어 스타일은 흐름 제어를 어렵게 만듭니다.
- XSLT 2.0은 지원되지 않습니다. (XSLT 1.0은 훨씬 실용적이지 않습니다).
답변
나의 현재 선택은 면도기입니다. 매우 깨끗하고 읽기 쉽고보기 페이지를 유지 관리하기가 매우 쉽습니다. 정말 훌륭한 지적 지원도 있습니다. ALos, 웹 헬퍼와 함께 사용하면 정말 강력합니다.
간단한 샘플을 제공하려면
@Model namespace.model
<!Doctype html>
<html>
<head>
<title>Test Razor</title>
</head>
<body>
<ul class="mainList">
@foreach(var x in ViewData.model)
{
<li>@x.PropertyName</li>
}
</ul>
</body>
그리고 거기 있습니다. 매우 깨끗하고 읽기 쉽습니다. 물론 이것은 단순한 예이지만 복잡한 페이지와 양식에서도 여전히 읽고 이해하기가 매우 쉽습니다.
단점은? 지금까지 양식에 도우미를 사용할 때 약간 성가신 CSS 클래스 참조를 추가 할 수있는 지원이 부족합니다.
감사합니다 Nathj07
답변
이것이 실제로 귀하의 질문에 대답하지는 않지만 다른 View Engine의 목적은 다릅니다. 스파크보기 엔진은 , 예를 들어, 목적은 모든 유창하게 읽을 수 있도록 노력하여 “태그 수프”당신의 견해를 제거합니다.
가장 좋은 방법은 일부 구현을 보는 것입니다. 솔루션의 의도에 호소력이 있다면 그것을 사용해보십시오. MVC에서 뷰 엔진을 혼합하고 일치시킬 수 있으므로 특정 엔진을 사용하지 않기로 결정해도 문제가되지 않습니다.
답변
이 SharpDOM을 확인하십시오 . 이것은 HTML 및 asp.net mvc보기 엔진을 생성하기위한 AC # 4.0 내부 dsl입니다.
답변
나는 ndjango를 좋아 한다 . 사용이 매우 쉽고 유연합니다. 사용자 정의 태그 및 필터를 사용하여보기 기능을 쉽게 확장 할 수 있습니다. 나는 “F #에 크게 묶여있다”는 단점보다는 오히려 유리하다고 생각한다.
답변
이 목록에는 각보기 엔진의 샘플도 포함되어야하므로 사용자는 모든 웹 사이트를 방문하지 않고도 각각의 맛을 얻을 수 있습니다.
그림은 천 단어를 말하고 마크 업 샘플은 뷰 엔진의 스크린 샷과 같습니다. 🙂 여기 내가 좋아하는 Spark View Engine 의 스크린 샷이 있습니다
<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>