ASP.NET MVC ビューエンジンの比較

https://stackoverflow.com/questions/1451319

12-09-2019
|

質問

ASP.NET MVC で利用できるさまざまなビューエンジンの内訳を SO と Google で検索してきましたが、ビューエンジンとは何かについての簡単な概要説明以上のものは見つかりませんでした。

私は必ずしも「最高」または「最速」を探しているわけではなく、むしろ主要なプレーヤーの長所と短所の実際の比較をいくつか探しています（例：さまざまな状況に対応するデフォルトの WebFormViewEngine、MvcContrib View Engine など）。これは、デフォルトのエンジンから切り替えることが特定のプロジェクトまたは開発グループにとって有利かどうかを判断するのに非常に役立つと思います。

誰かがそのような比較に遭遇したことがありますか？

解決

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

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

System.Web.Mvc.WebFormViewEngine

設計目標:

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

長所:

ASP.NET MVC に同梱されているためユビキタスです
ASP.NET開発者にとって使い慣れたエクスペリエンス
インテリセンス
CodeDom プロバイダーを使用して任意の言語を選択できます (例:C#、VB.NET、F#、Boo、Nemerle)
オンデマンドのコンパイルまたはプリコンパイル済みビュー

短所:

MVC では適用されなくなった「クラシック ASP.NET」パターンの存在により、使用方法が混乱しています (例:ViewState ポストバック)
「タグスープ」のアンチパターンに寄与する可能性がある
コードブロック構文と強い型指定が邪魔になる可能性がある
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 View Engineは、Microsoft Asp.Net MVCフレームワークで動作するためにモノレールから移植されています。ブレイルの紹介については、のドキュメントを参照してくださいキャッスルプロジェクトのウェブサイト.

長所:

「手首に優しい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

NDジャンゴ

設計目標:

NDjango は、 Django テンプレート言語 .NETプラットフォームで、を使用して F# 言語.

長所:

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

ナムル

設計目標:

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

Hamlは、インラインコードを使用せずに、任意のWebドキュメントのXHTMLをきれいにして単純に説明するために使用されるマークアップ言語です...Hamlは、XHTMLをテンプレートに明示的にコーディングする必要性を回避します。これは、実際には動的コンテンツを生成するためのいくつかのコードを使用してXHTMLの抽象的な説明であるためです。

長所:

簡潔な構造 (すなわち、ドライ。）
よく凹んだ
明確な構造
C# インテリセンス (ReSharper を使用しない VS2008 の場合)

短所:

使い慣れたマークアップを利用するのではなく、XHTML からの抽象化
VS2010 にはインテリセンスがありません

例：

@type=IEnumerable<Product>
- if(model.Any())
  %ul
    - foreach (var p in model)
      %li= p.Name
- else
  %p No products available

NVelocityViewEngine (MvcContrib)

設計目標:

に基づくビューエンジン N速度人気の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

設計目標:

軽量。ページクラスは作成されません。

速い。テンプレートは応答出力ストリームに書き込まれます。

キャッシュされました。テンプレートはキャッシュされていますが、ファイルシステムウォッチャーを使用してファイルの変更を検出します。

動的。テンプレートはコード内でオンザフライで生成できます。

フレキシブル。テンプレートは任意のレベルにネストできます。

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

私は、これは本当にあなたの質問に答えていない知っているが、異なるビュー・エンジンは、異なる目的を持っています。ビューエンジンをスパークrel="noreferrer">の

あなたの最善の策は、単にいくつかの実装を見てだろう。それはあなたのソリューションの意図に魅力的に見える場合は、それを試してみてください。あなたが混在し、MVCでの試合ビューエンジンなので、あなたが特定のエンジンに行かないことにした場合、それは問題ではありませんすることができます。

この SharpDOM のを確認してください。これはHTMLを生成し、また、MVCビューエンジンをASP.NETのC＃4.0内部DSLである。

私は ndjango のが好きです。非常に使いやすい、非常に柔軟です。あなたは簡単にカスタムタグやフィルタとビュー機能を拡張することができます。私はむしろ不利よりも有利である「大幅のF＃に結び付け」だと思います。

私は、ユーザーがすべてのウェブサイトを訪問することなく、それぞれの味を得ることができるので、このリストには、各ビューエンジンのサンプルを含めるべきだと思います。

の写真は千個の言葉とマークアップのサンプルは:)ビューエンジンのスクリーンショットのようなものですので、ここで私のお気に入りのスパークビューエンジン<1からだと言います/>

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

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow

ASP.NET MVC ビュー エンジンの比較

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

ASP.NET MVC ビューエンジンの比較

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