What are the benefits of using an alternate view engine?_问答_开发者

I am playing with ASP.NET MVC and I see that there are a few alternate view engines available for it such as NHaml and Spark. My question is why would you use an alternate view engine? I don't see a benefit to having something like this:

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

using the Spark view engine (doubly so since, and I haven't used Spa开发者_Go百科rk to verify this and might be totally wrong, you wouldn't get Intellisense since you're passing the code as a string) and:

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

using the built-in ASP.NET MVC template format (although I admit the dangling curly brace is pretty ugly). Is there any legitimate reason apart from not like the "gator" tags (or dangling curly braces) to consider using an alternate view engine? Or is it just cool because it's something new?

Try to make it a bit more complex:

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

I can see the flow here. I can actually see HTML here. Now take a look:

<% 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++; } %>
<% } %>

I'm lost here. Is there any HTML there?

For me, this is the main reason. Of course, Spark gives TONS of features - macros (where you code your Html.Helpers in spark markup), PDF export, etc - listed by others - but as a programmer I prefer clean code.

As another example, do you often use for (int i = 0; i < products.Count; i++) { Product product = products[i]; .... } these days? Would you prefer foreach (var product in products) {}? I would. Not only because it's less to type. Because:

it expresses the intent better
it reads better
it hides additional details (like .Count, .Length, or .Count(); or if it's IEnumerable that you have to traverse in a special way) from my tired mind
it reduces number of variables cluttering the context (and my tired mind)
thus I can concentrate on the problem, nothing goes in the way
it helps to avoid {} since there's no need to have a variable inside - reducing line count
and when you change the collection from IList to array, you don't change 50 loops all over the place

and that's about such simple thing as foreach. Each reason is simple, but they sum up to something bigger. And these reasons apply perfectly to Spark. Hey, looks like I'm in love ;-)

Update: now, you know what? Look at my post's edit history. I had to edit the damn ASP code several times just because I missed some bits here and there. I just do not see if it's right or wrong. It's completely hidden if I have the span there, or condition at place.

Update: hm, yet another edit... moving ASP's if/span inside li...

I think the question you need to ask is "why you want to change view engines" rather than "Should I change view engines"

I chose spark because I wanted cleaner looking views and I also wanted to use it to create templates for things other than HTML. I currently use it for generating XML, JSON and email templates so it's become a templating engine for me as well as a view engine. This is made possible because it allows you to render views to strings rather, which isn't (easily) available in the standard view engine.

It's also important to note that you don't have to use a single view engine either. You can use multiple engines at the same time so you might use the default view engine for HTML templates, but switch to spark for XML.

Overall, if the default view engine is doing everything you need and you're happy with it then I wouldn't bother switching at all, however if you have specific needs that aren't being met by the default view engine then maybe it's time to look at alternatives.

Personally, I don't use alternate view engines, but their appeal is that of cleaner views. If you're fluent in Spark, that first example is a lot nicer and easier to read.

However, I prefer to wrap logic such as what you have given into a helper method. I don't have to learn something new, all of my coworkers can understand it, and my views stay relatively clean. It's a completely subjective matter, and either approach is fine.

These view engines are largely a carry-over from other frameworks like RoR and Django. Django's argument for its view templating system is that views should only be for view logic. Therefore, if you restrict what is possible in your view engine, you have fewer opportunities to mix up responsibilities between controllers and views.

I'd say it's more of an option than anything else. It's like deciding between C# and Visual Basic, use what you know best and what you will be more productive in.

Some of benefits of Spark (what I like):

You can use partial views like html tags. Example of use can be tag for rounded corners.
You don't get "tag soup". Maybe you don't see benefit right now, but if you have huge views, it is much more readable.
You get strongly typed access to ViewData["..."].
You can easily render views to string.
Automatically applies Html.Encode, increasing safety of your application.

What I don't like: