5

ASP.NET MVCで遊んでいますが、NHamlやSparkなどの代替ビューエンジンがいくつかあることがわかります。私の質問は、なぜ代替ビューエンジンを使用するのかということです。私はこのようなものを持つことの利点を見ていません：

<ul if="products.Any()">
    <li each="var p in products">${p.Name}</li>
</ul>
<else>
    <p>No products available</p>
</else>

Sparkビューエンジンを使用する（これ以降、Sparkを使用してこれを検証していないため、完全に間違っている可能性があります。コードを文字列として渡すため、Intellisenseを取得できません）。

<% if products.Any() { %>
    <ul>
      <% foreach (var p in products) { %>
        <li><%= p.Name %></li>
      <% } %>  
    </ul>
<% } else { %>
    <p>No products available</p>
<% } %>

組み込みのASP.NETMVCテンプレート形式を使用します（ただし、ぶら下がっている中括弧はかなり醜いです）。代替ビューエンジンの使用を検討する「ワニ」タグ（または中かっこがぶら下がっている）が好きではないこと以外に、正当な理由はありますか？それとも、何か新しいものだからかっこいいですか？

4

5 に答える 5

5

もう少し複雑にしてみてください。

<div if="orders.Any()" each="var order in orders">
  Here's your order #${orderIndex+1}:
  <ul>
    <li each="var p in order.Products">
       ${pIndex}: ${p.Name}
       <span if="pIsLast"> (the end)</span>
    </li>
  </ul>
</div>

ここに流れが見えます。私は実際にここでHTMLを見ることができます。今見てみましょう：

<% if (orders.Any()) { %>
  <% var orderIndex = 0; foreach (var order in orders") { %>
   <div>
    Here's your order #<%= (orderIndex+1) %>
    <ul>
      <% int pIndex = 0; foreach (var p in order.Products) 
         { bool pIsLast = pIndex == products.Count; %>
        <li>
           <%= pIndex %>: <%= p.Name %>
           <% if (pIsLast) { %>
              <span> (the end)</span>
           <% } %>
        </li>
      <% ++ pIndex; } %>  
    </ul>
   </div>
  <% orderIndex++; } %>
<% } %>

私はここで迷子になっています。そこにHTMLはありますか？

私にとって、これが主な理由です。もちろん、Sparkは、マクロ（Html.Helpersをsparkマークアップでコーディングする）、PDFエクスポートなど、他の人がリストした多くの機能を提供しますが、プログラマーとしてはクリーンなコードを好みます。

別の例として、（int i = 0; i <products.Count; i ++）{Product product = products [i];をよく使用しますか？.... } この日？foreach（var product in products）{}を選択しますか？私は...するだろう。入力が少ないという理由だけではありません。なぜなら：

  • それは意図をよりよく表現します
  • 読みやすく
  • それは私の疲れた心から追加の詳細（.Count、.Length、または.Count（）;または特別な方法でトラバースする必要があるIEnumerableの場合）を隠します
  • コンテキスト（および私の疲れた心）を乱雑にする変数の数を減らします
  • したがって、私は問題に集中することができます、何も邪魔になりません
  • 内部に変数を含める必要がないため、{}を回避するのに役立ちます-行数を減らします
  • コレクションをIListから配列に変更しても、50のループは変更されません。

これは、foreachのような単純なことです。それぞれの理由は単純ですが、合計するとさらに大きなものになります。そして、これらの理由はSparkに完全に当てはまります。ねえ、私は恋をしているようだ;-)

更新：今、あなたは何を知っていますか？私の投稿の編集履歴を見てください。あちこちでいくつかのビットを逃したという理由だけで、私はいまいましいASPコードを数回編集しなければなりませんでした。私はそれが正しいか間違っているかわかりません。そこにスパンがあるか、その場でコンディションがあれば、それは完全に隠されています。

更新：うーん、さらに別の編集...ASPのif/spanをli内に移動...

于 2009-11-19T21:55:19.233 に答える
2

あなたが尋ねる必要がある質問は、「ビューエンジンを変更する必要がある」ではなく、「なぜビューエンジンを変更したいのか」だと思います。

Sparkを選択したのは、見た目がすっきりしたビューが必要であり、HTML以外のテンプレートを作成するためにも使用したかったためです。現在、XML、JSON、および電子メールテンプレートの生成に使用しているため、ビューエンジンであると同時にテンプレートエンジンにもなっています。これが可能になるのは、ビューを文字列にレンダリングできるためです。これは、標準のビューエンジンでは（簡単に）利用できません。

また、単一のビューエンジンを使用する必要がないことに注意することも重要です。複数のエンジンを同時に使用できるため、HTMLテンプレートにはデフォルトのビューエンジンを使用できますが、XMLにはsparkに切り替えます。

全体として、デフォルトのビューエンジンが必要なすべてを実行していて、それに満足している場合は、切り替える必要はまったくありませんが、デフォルトのビューエンジンで満たされていない特定のニーズがある場合は、おそらくその時です代替案を検討します。

于 2009-11-11T23:39:40.480 に答える
1

個人的には代替ビューエンジンは使用していませんが、よりクリーンなビューが魅力です。Sparkに精通している場合は、最初の例の方がはるかに優れており、読みやすくなっています。

ただし、私はあなたが与えたものなどのロジックをヘルパーメソッドにラップすることを好みます。私は何か新しいことを学ぶ必要はありません、私の同僚全員がそれを理解することができます、そして私の見解は比較的きれいなままです。それは完全に主観的な問題であり、どちらのアプローチでも問題ありません。

これらのビューエンジンは、主にRoRやDjangoなどの他のフレームワークから引き継がれています。ビューテンプレートシステムに対するDjangoの主張は、ビューはビューロジック専用である必要があるというものです。したがって、ビューエンジンで可能なことを制限すると、コントローラーとビューの間で責任を混同する機会が少なくなります。

于 2009-11-11T23:31:16.240 に答える
1

私はそれが何よりもオプションだと思います。これは、C＃とVisual Basicのどちらを使用するかを決定するようなもので、最もよく知っているものと、より生産性の高いものを使用します。

于 2009-11-12T00:03:44.177 に答える
0

Sparkの利点のいくつか（私が好きなもの）：

  1. htmlタグのような部分的なビューを使用できます。使用例として、角の丸いタグを付けることができます。
  2. 「タグスープ」はもらえません。たぶんあなたは今のところ利益を見ていませんが、あなたが巨大な見解を持っているなら、それははるかに読みやすいです。
  3. ViewData["..."]への強い型のアクセスを取得します。
  4. ビューを文字列に簡単にレンダリングできます。
  5. Html.Encodeを自動的に適用し、アプリケーションの安全性を高めます。

私が好きではないもの：

  1. IntellisenseとResharperに問題があります。
  2. [ドキュメントのフォーマット]オプションは使用できません。

私はSparkでこの問題を解決しましたが、標準のビューエンジンを使用する理由はありません。

于 2009-11-11T23:58:57.867 に答える