ASP.NET MVCビューエンジン（コミュニティWiki）
包括的なリストが存在しないように見えるので、ここから始めましょう。これは、ASP.NET MVCコミュニティ（たとえば、これらのいずれかに貢献した人）が経験を追加した場合に非常に役立ちます。実装するものIViewEngine（たとえばVirtualPathProviderViewEngine）は、ここでは公平なゲームです。新しいビューエンジンをアルファベット順に並べて（WebFormViewEngineとRazorを上部に残して）、比較で客観的になるようにしてください。
System.Web.Mvc.WebFormViewEngine
設計目標：
Webフォームページを応答にレンダリングするために使用されるビューエンジン。
長所：
- 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
詐欺の例＃1（ "string [] ..."の配置に注意してください）：
@{
<h3>Team Members</h3> string[] teamMembers = {"Matt", "Joanne", "Robert"};
foreach (var person in teamMembers)
{
<p>@person</p>
}
}
ベルビュー
設計目標：
- HTMLを「単なるテキスト」として扱うのではなく、ファーストクラスの言語として尊重してください。
- HTMLをいじらないでください！データバインディングコード（Bellevueコード）はHTMLから分離する必要があります。
- 厳密なモデルとビューの分離を実施する
手すり
設計目標：
BrailビューエンジンがMonoRailから移植され、Microsoft ASP.NET MVCフレームワークで動作するようになりました。Brailの概要については、CastleプロジェクトWebサイトのドキュメントを参照してください。
長所：
- 「手首に優しい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
設計目標：
NDjangoは、FNET 言語を使用した.NETプラットフォーム上のDjangoテンプレート言語の実装
です。
長所：
NHaml
設計目標：
Rails Hamlビューエンジンの.NETポート。Hamlウェブサイトから：
Hamlは、インラインコードを使用せずに、任意のWebドキュメントの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>
Spark View Engine
設計目標：
アイデアは、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はあまり実用的ではありません）。