ASP.NET MVC ビューエンジンの比較質問する

Question

ASP.NET MVC ビューエンジン (コミュニティ Wiki)

包括的なリストは存在しないようなので、SO でリストを作成しましょう。人々が自分の経験を追加すれば (特に、これらのいずれかに貢献した人)、これは ASP.NET MVC コミュニティにとって非常に価値のあるものになります。実装するものIViewEngine(例VirtualPathProviderViewEngine) はすべてここで対象となります。新しいビューエンジンをアルファベット順に並べ (WebFormViewEngine と Razor を先頭に残します)、比較は客観的に行うようにしてください。

System.Web.Mvc.Webフォームビューエンジン

設計目標:

応答に対して Web フォームページをレンダリングするために使用されるビューエンジン。

長所:

ASP.NET MVCを搭載しているので、どこにでも存在する
ASP.NET開発者にとって馴染みのある体験
インテリセンス
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>
<%}%>

システム.Web.Razor

設計目標:

長所:

コンパクト、表現力豊か、そして流動的
簡単に学べる
新しい言語ではない
優れたインテリセンスを備えている
ユニットテスト可能
ユビキタス、ASP.NET MVC 搭載

短所:

上で言及した「タグスープ」とは少し異なる問題が発生します。サーバータグは実際にはサーバーコードと非サーバーコードの周囲に構造を提供しますが、Razor は HTML とサーバーコードを混同し、特定の非常に一般的な状況下で HTML や JavaScript タグを「エスケープ」する必要が生じるため、純粋な HTML または JS 開発が困難になります (欠点例 #1 を参照)。
カプセル化と再利用性が不十分: 通常のメソッドであるかのように Razor テンプレートを呼び出すのは非現実的です。実際には Razor はコードを呼び出すことができますが、その逆はできないため、コードとプレゼンテーションが混在する可能性があります。
構文は HTML 指向が強いため、非 HTML コンテンツの生成は難しい場合があります。それにもかかわらず、Razor のデータモデルは基本的に文字列の連結だけなので、構文エラーやネストエラーは静的にも動的にも検出されません。ただし、VS.NET のデザイン時ヘルプによって、この問題はいくらか軽減されます。このため、保守性とリファクタリング性が低下する可能性があります。
~~文書化されたAPIはありません~~ 。http://msdn.microsoft.com/en-us/library/system.web.razor.aspx

反対の例 #1 (「string[]...」の配置に注意してください):

@{
    <h3>Team Members</h3> string[] teamMembers = {"Matt", "Joanne", "Robert"};
    foreach (var person in teamMembers)
    {
        <p>@person</p>
    }
}

ベルビュー

設計目標:

HTML を「単なるテキスト」として扱うのではなく、第一級の言語として尊重します。

HTML をいじらないでください。データバインディングコード (Bellevue コード) は HTML とは別にする必要があります。

厳密なモデルとビューの分離を強制する

点字

設計目標:

Brailビューエンジンは、Microsoft ASP.NET MVCフレームワークで動作するようにMonoRailから移植されました。Brailの紹介については、キャッスルプロジェクトのウェブサイト。

長所:

「手首に優しいPython構文」をモデルにしています
オンデマンドでコンパイルされたビュー（ただし、プリコンパイルは利用できません）

短所:

言語で書かれるように設計されているブー

例：

<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は、Django テンプレート言語.NETプラットフォームでは、F#言語。

長所:

NDjangoリリース0.9.1.0は、ストレス下でもより安定しているようだ。WebFormViewEngine
構文の色分け、コード補完、入力時の診断機能を備えた Django テンプレートエディター (VS2010 のみ)
ASP.NET、Castle MonoRail、Bistro MVCフレームワークと統合

Nハムル

設計目標:

Rails Hamlビューエンジンの.NETポート。ハムルのウェブサイト:

Haml は、インラインコードを使用せずに、Web ドキュメントの XHTML を簡潔かつ簡潔に記述するために使用されるマークアップ言語です。Haml は実際には XHTML の抽象的な記述であり、動的なコンテンツを生成するコードが含まれているため、テンプレートに XHTML を明示的にコーディングする必要がありません。

長所:

簡潔な構造（つまりDRY）
よくインデントされた
明確な構造
C# インテリセンス(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)

設計目標:

ビューエンジンはNVelocityこれは人気のJavaプロジェクトの.NETポートです速度。

長所:

読み書きが簡単
簡潔なビューコード

短所:

ビューで利用できるヘルパーメソッドの数が限られている
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コンセプトと組み合わせることでタイルフレームワーク(マイルストーン1時点)

長所:

Java開発者にはお馴染み
XMLスタイルのコードブロック

短所:

...

例：

<c:if test="${not fn:empty(Page.Tiles)}">
  <p class="note">
    <fmt:message key="page.tilesSupport"/>
  </p>
</c:if>

Spark View エンジン

設計目標:

アイデアは、HTML がフローを支配し、コードがシームレスに適合できるようにすることです。

長所:

より読みやすいテンプレートを作成する
C# インテリセンス(ReSharper なしの VS2008 の場合)
SparkSenseプラグインVS2010用（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 ビューエンジン 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 はあまり実用的ではありません)。

Answer 1

ASP.NET MVC ビューエンジン (コミュニティ Wiki)

包括的なリストは存在しないようなので、SO でリストを作成しましょう。人々が自分の経験を追加すれば (特に、これらのいずれかに貢献した人)、これは ASP.NET MVC コミュニティにとって非常に価値のあるものになります。実装するものIViewEngine(例VirtualPathProviderViewEngine) はすべてここで対象となります。新しいビューエンジンをアルファベット順に並べ (WebFormViewEngine と Razor を先頭に残します)、比較は客観的に行うようにしてください。

System.Web.Mvc.Webフォームビューエンジン

設計目標:

応答に対して Web フォームページをレンダリングするために使用されるビューエンジン。

長所:

ASP.NET MVCを搭載しているので、どこにでも存在する
ASP.NET開発者にとって馴染みのある体験
インテリセンス
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>
<%}%>

システム.Web.Razor

設計目標:

長所:

コンパクト、表現力豊か、そして流動的
簡単に学べる
新しい言語ではない
優れたインテリセンスを備えている
ユニットテスト可能
ユビキタス、ASP.NET MVC 搭載

短所:

上で言及した「タグスープ」とは少し異なる問題が発生します。サーバータグは実際にはサーバーコードと非サーバーコードの周囲に構造を提供しますが、Razor は HTML とサーバーコードを混同し、特定の非常に一般的な状況下で HTML や JavaScript タグを「エスケープ」する必要が生じるため、純粋な HTML または JS 開発が困難になります (欠点例 #1 を参照)。
カプセル化と再利用性が不十分: 通常のメソッドであるかのように Razor テンプレートを呼び出すのは非現実的です。実際には Razor はコードを呼び出すことができますが、その逆はできないため、コードとプレゼンテーションが混在する可能性があります。
構文は HTML 指向が強いため、非 HTML コンテンツの生成は難しい場合があります。それにもかかわらず、Razor のデータモデルは基本的に文字列の連結だけなので、構文エラーやネストエラーは静的にも動的にも検出されません。ただし、VS.NET のデザイン時ヘルプによって、この問題はいくらか軽減されます。このため、保守性とリファクタリング性が低下する可能性があります。
~~文書化されたAPIはありません~~ 。http://msdn.microsoft.com/en-us/library/system.web.razor.aspx

反対の例 #1 (「string[]...」の配置に注意してください):

@{
    <h3>Team Members</h3> string[] teamMembers = {"Matt", "Joanne", "Robert"};
    foreach (var person in teamMembers)
    {
        <p>@person</p>
    }
}

ベルビュー

設計目標:

HTML を「単なるテキスト」として扱うのではなく、第一級の言語として尊重します。

HTML をいじらないでください。データバインディングコード (Bellevue コード) は HTML とは別にする必要があります。

厳密なモデルとビューの分離を強制する

点字

設計目標:

Brailビューエンジンは、Microsoft ASP.NET MVCフレームワークで動作するようにMonoRailから移植されました。Brailの紹介については、キャッスルプロジェクトのウェブサイト。

長所:

「手首に優しいPython構文」をモデルにしています
オンデマンドでコンパイルされたビュー（ただし、プリコンパイルは利用できません）

短所:

言語で書かれるように設計されているブー

例：

<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は、Django テンプレート言語.NETプラットフォームでは、F#言語。

長所:

NDjangoリリース0.9.1.0は、ストレス下でもより安定しているようだ。WebFormViewEngine
構文の色分け、コード補完、入力時の診断機能を備えた Django テンプレートエディター (VS2010 のみ)
ASP.NET、Castle MonoRail、Bistro MVCフレームワークと統合

Nハムル

設計目標:

Rails Hamlビューエンジンの.NETポート。ハムルのウェブサイト:

Haml は、インラインコードを使用せずに、Web ドキュメントの XHTML を簡潔かつ簡潔に記述するために使用されるマークアップ言語です。Haml は実際には XHTML の抽象的な記述であり、動的なコンテンツを生成するコードが含まれているため、テンプレートに XHTML を明示的にコーディングする必要がありません。

長所:

簡潔な構造（つまりDRY）
よくインデントされた
明確な構造
C# インテリセンス(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)

設計目標:

ビューエンジンはNVelocityこれは人気のJavaプロジェクトの.NETポートです速度。

長所:

読み書きが簡単
簡潔なビューコード

短所:

ビューで利用できるヘルパーメソッドの数が限られている
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コンセプトと組み合わせることでタイルフレームワーク(マイルストーン1時点)

長所:

Java開発者にはお馴染み
XMLスタイルのコードブロック

短所:

...

例：

<c:if test="${not fn:empty(Page.Tiles)}">
  <p class="note">
    <fmt:message key="page.tilesSupport"/>
  </p>
</c:if>

Spark View エンジン

設計目標:

アイデアは、HTML がフローを支配し、コードがシームレスに適合できるようにすることです。

長所:

より読みやすいテンプレートを作成する
C# インテリセンス(ReSharper なしの VS2008 の場合)
SparkSenseプラグインVS2010用（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 ビューエンジン 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 はあまり実用的ではありません)。

ASP.NET MVC ビューエンジンの比較質問する

ベストアンサー1

ASP.NET MVC ビューエンジン (コミュニティ Wiki)

おすすめ記事

ベストアンサー1

ASP.NET MVC ビュー エンジン (コミュニティ Wiki)

おすすめ記事

ASP.NET MVC ビューエンジン (コミュニティ Wiki)