[asp.net-mvc] ASP.NET MVC 뷰 엔진 비교

나는 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>
<%}%>

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 프로젝트 웹 사이트 의 문서를 참조하십시오 .

장점 :

“손목 친화적 인 파이썬 구문”을 모델링
요청시 컴파일 된 뷰 (사용 가능한 사전 컴파일은 없음)

단점 :

언어 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

설계 목표 :

NDjango는 F # 언어를 사용하여 .NET 플랫폼 에서 Django 템플릿 언어 를 구현 한 것입니다
.

장점 :

NDjango 릴리스 0.9.1.0은 스트레스 하에서보다 안정적 인 것으로 보입니다. WebFormViewEngine
구문 색상 지정, 코드 완성 및 사용자 진단 기능을 갖춘 Django 템플릿 편집기 (VS2010 만 해당)
ASP.NET, Castle MonoRail 및 Bistro MVC 프레임 워크와 통합

NHaml

설계 목표 :

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

설계 목표 :

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을 나타내는 코드를 작성합니다.

XsltViewEngine (MvcContrib)

설계 목표 :

익숙한 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>