web-dev-qa-db-ja.com

ASP.NET MVC View Engineの比較

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

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

誰もそのような比較に遭遇しましたか？

asp.net-mvcspark-view-engineviewenginerazor
336
mckamey

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

設計目標：

長所：

  • コンパクトで表現力豊かで流動的
  • 簡単に学べる
  • 新しい言語ではない
  • 素晴らしいインテリセンスを持っています
  • ユニットテスト可能
  • ユビキタス、ASP.NET MVCとともに出荷

短所：

  • 上記の「タグスープ」とは少し異なる問題を作成します。サーバータグが実際にサーバーコードと非サーバーコードの周囲の構造を提供する場合、RazorはHTMLコードとサーバーコードを混同し、純粋なHTMLまたはJS開発を困難にします（Con例＃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を台無しにしないでください！データバインディングコード（Bellevueコード）はHTMLから分離する必要があります。
  • 厳密なモデルビュー分離を強制する

ブレール （

設計目標：

Brailビューエンジンは、Microsoft ASP.NET MVCフレームワークで動作するようにMonoRailから移植されました。 Brailの概要については、 CastleプロジェクトのWebサイト のドキュメントを参照してください。

長所：

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

短所：

  • 言語で記述されるように設計されている 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

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は、.NETプラットフォームでの F＃言語 を使用した Djangoテンプレート言語 の実装です。

長所：

NHaml

設計目標：

Rails Hamlビューエンジンの.NETポート。 Haml Webサイト から：

Hamlは、インラインコードを使用せずに、WebドキュメントのXHTMLを簡潔かつ単純に記述するために使用されるマークアップ言語です... 、動的コンテンツを生成するためのコードを使用します。

長所：

  • 簡潔な構造（すなわち、D.R.Y。）
  • よくインデントされている
  • 明確な構造
  • 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） （

設計目標：

NVelocity に基づくビューエンジン。これは、人気のあるJavaプロジェクトの.NETポートです Velocity 。

長所：

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

短所：

  • ビューで使用できるヘルパーメソッドの数が限られている
  • 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>

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 View Engine MVC

設計目標：

  • 軽量。ページクラスは作成されません。
  • 速い。テンプレートは、応答出力ストリームに書き込まれます。
  • キャッシュされます。テンプレートはキャッシュされますが、FileSystemWatcherを使用してファイルの変更を検出します。
  • 動的。テンプレートは、コードでその場で生成できます。
  • フレキシブル。テンプレートは任意のレベルにネストできます。
  • MVCの原則に沿って。 UIとビジネスロジックの分離を促進します。すべてのデータは事前​​に作成され、テンプレートに渡されます。

長所：

  • stringTemplate Java開発者になじみがある

短所：

  • 単純なテンプレート構文は、意図した出力を妨げる可能性があります（例 jQuery conflict ）

ウイングビート

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はあまり実用的ではありません）。
429
mckamey

私の現在の選択はカミソリです。これは非常にクリーンで読みやすく、ビューページのメンテナンスが非常に簡単です。本当に素晴らしいインテリセンスのサポートもあります。また、Webヘルパーと併用すると、非常に強力です。

簡単なサンプルを提供するには：

@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

17
nathj07

これは実際にはあなたの質問に答えるものではありませんが、View Engineによって目的は異なります。 Spark View Engine は、例えば、すべてを流で読みやすいものにすることにより、「タグスープ」のビューを取り除くことを目的としています。

あなたの最善の策は、いくつかの実装を見ることです。ソリューションの目的に合っていると思われる場合は、試してみてください。 MVCでビューエンジンを組み合わせて使用​​できるため、特定のエンジンを使用しない場合でも問題はありません。

10
MunkiPhD

これを確認してください SharpDOM 。これは、htmlおよびasp.net mvcビューエンジンを生成するためのc＃4.0内部dslです。

8
Anton Shelin

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

5
rdovhan

ユーザーがすべてのWebサイトにアクセスしなくても各ビューエンジンのサンプルを取得できるように、このリストには各ビューエンジンのサンプルも含める必要があると思います。

写真は千の言葉を言い、マークアップのサンプルはビューエンジンのスクリーンショットのようなものです:)だからここに私のお気に入りの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>
4
mythz