Is Razor or XSLT better for my project? [closed]

Question

I'm in the early stages in the design of a system that will essentially be split into two parts. One part is a service and the other is an interface with the service providing data through something like OData or XML. The application will be based on the MVC architectural pattern. For the views, we are considering using either XSLT or Razor under ASP.NET.

XSLT or Razor would help to provide a separation of concerns where the original XML or response represents your model, the XSLT or 'Razor view' represents your view. I'll leave the controller out for this example. The initial design proposal recommends XSLT, however I suggested the use of Razor instead as a more friendly view engine.

These are the reasons I suggested for Razor (C#):

• Easier to work with and build more complicated pages.
• Can easily produce non-*ML output, eg csv, txt, fdf
• Less verbose templates
• The view model is strongly typed, where XSLT would need to rely on convention, eg boolean or date values
• Markup is more approachable, eg nbsp, newline normalization, attibute value normalization, whitespace rules
• Built in HTML helper can generate JS validation code based on DTO attributes
• Built in HTML helper can generate links to actions

And the arguments for XSLT over razor were:

• XSLT is a standard and will still exist many years into the future.
• It is hard to accidentally move logic into the view
• Easer for non programmers (which I don't agree with).
• It's been successful in some of our past projects.
• Data values are HTML-encoded by default
• Always well formed

So I'm looking for aguments on either side, recommendations or any experience making a similar choice?

Answer 1

I HAVE successfully used XSLT as a web presentation tier... in 1999. In the last 12 years, much better options have come along. Do yourself a big favor, and use Razor. It's a pleasure.

Answer 2

Here is a basic syntax comparison

Razor

@foreach(var item in View.List) {
  <span>@item.Name</span><br/>
}

XSLT

  <xsl:template match="/">
    <xsl:apply-templates/>
  </xsl:template>

  <xsl:template match="item">
    <xsl:for-each select="name">
      <xsl:value-of select="."/><br/>
    </xsl:for-each>
  </xsl:template>

</xsl:stylesheet>

The data sources for the two examples

XML

<?xml version="1.0" standalone="no"?>
<?xml-stylesheet type="text/xsl" href="transform.xsl"?>
<list>
    <item>
        <name>List item one</name>
        <url>http://site.com/one</url>
    </item>
    <item>
        <name>List item two</name>
        <url>http://site.com/two</url>
    </item>
</list>

C#

ViewModel.List = new[] {
    new Link {
        Name = "List item one",
        Url = "http://site.com/one"
    },
    new Link {
        Name = "List item two",
        Url = "http://site.com/two"
    }
};

Answer 3

Is there a 1:1 relation between HTML pages and XML output? Consider following cases:

• Strong correlation: each web page has an HTML and a corresponding XML form.

Example: you're hosting a website with movies reviews. You have a home page with latest reviews, one page per review and a page with guests comments and ratings. There is no registration whatsoever. You want to make it easy to use your website programmatically without the ugly HTML parsing. In this case, you can have a 1:1 relation: all the human can do, the bot can do too: with same requests, they will obtain the same content.

http://example.com/Movie/View/12345/The%20Adjustment%20Bureau is used by humans.
http://example.com/Movie/View/12345/The%20Adjustment%20Bureau?xml is used by bots to access the same information.

• Weak or no correlation: there is just a bunch of web services on one side, and a bunch of web pages on the other.

Example: you're a creator of another Facebook. There is a website, and there is an API. The only common point is that the same database is used, but bots cannot access what people can, and the information is presented differently.

http://example.com/MyFriends/ shows the top ten of friends I have in my account. By clicking "More", an AJAX request is made, showing other friends.
http://api.example.com/friends?user=MainMa&key=1DE051C6F&xml shows the corresponding XML with all friends I have.

You can see that:

• The API is hosted separately, on a distinct server,
• The relation between pages and API is hard to see.
• The website needs to use sessions to track logons. The API needs just a generated key to be sent on every request.
• The number of requests is not the same. In one case, you have to query the page, then do an AJAX request to obtain the rest of your friends. In other case, you obtain the whole list at once.
• The returned information is not the same. As a human, you identify your friends by their name. A bot using the API will identify them by their unique identifier which you may never see on the website.

---

I recommend choosing XSLT only if you are near a 1:1 relation. In this case, it will simplify the approach: the application will emit XML every time, but sometimes transform it with XSLT for the browsers.

If you don't have this relation, I don't see any benefit of XSLT over Razor. It provides a separation of concerns which Razor provides too. It allows you to modify HTML without the need to recompile the website, which Razor allows too.

As for the benefits you listed:

XSLT is a standard and will still exist many years into the future

Are you planning to make an application which will live for a very long time? Razor have chances to be used in four years, or at least be supported. The lifespan of most applications is less than four years, so...

Easer for non programmers (something which i could contend with).

Wait, what?! Even programmers find that XSLT sucks, is difficult to understand and to use. And when I talk to non-programmers about XML (not even close to XSLT), they cry and run away.

It's been successful in some of our past projects.

If your team never used Razor before, then consider the time required to learn it.

If your team used it, but those projects failed, consider analyzing why is it failed and was it because of Razor, and what could you do to avoid such failures in future projects.

Answer 4

My recommendation is Razor and the main reason is that it's much more easier to work with (than XSLT, and opposite to your enumerated argument in favor of XSLT, though, you're on my side). I have experience of working with both and Razor becomes exceptionally powerful in conditional statements, declarative helpers (functions in principal), branching, looping, etc.

After all, let's not forget Razor is a programming language (yeah, a template engine, or view engine, but implemented via a programming language like C# or VB.NET), while XSLT is more have a markup structure.

I think your scenario is like trying to select C# or T-SQL to write a complex business application. While T-SQL is pretty powerful in set operations, it simply breaks when you try to implement logic (if-else, switch, for, etc.) in it.

Answer 5

You don't have to choose, you can use both. In ASP.NET MVC you can use multiple view engines at the same time. In the project I'm currently working on I'm using XSLT for readonly views and Razor for forms. You can also use XSLT with Razor layout or Razor with XSLT layout. I'm using XSLT layout, so I simply use a Razor layout that calls the XSLT layout and passes the sections HTML as parameters:

@{ 
   Html.RenderPartial("~/Views/shared/htmlRaw.xsl", null, new ViewDataDictionary { 
      { "head", RenderSection("head", required: false) },
      { "content", RenderBody().ToString() }
   });
}

... and in htmlRaw.xsl you simply use disable-output-escaping="yes":

<div id="content">
   <xsl:value-of select="$content" disable-output-escaping="yes"/>
</div>

See Using Razor and XSLT in the same project.

Answer 6

I would suggest there's a third and better way: put two different thin front ends on top of a single service/application layer which has no UI as such.

So, rather than

UI -> converts to and from xml -> Service -> talks to -> Application Layer -> Model

use

UI -> talks to -> Application Layer -> manipulates -> Model
Service ^

and ensure that the UI and Service contain ONLY code that is unique to that interface. (apologies for the ASCII diagrams, best I can do right now)

The reason I would be concerned about either of the designs you are discussing is that it ties development of the user interface to development of the service, which is rarely how you want to work. If the business wants to add a piece of functionality to the user interface, you don't want to be forced to write that service before you can do it. You want to write the user interface part and then, assuming it is required in the service, reuse the code there.

Worse, if the business wants to display data very differently to the end-user from how it is presented to a mechanical user via the service (which seems highly likely), you're going to have to start putting complex code into XSLT, or build a second service layer (or worse, fat controllers) on top of your service to represent presentation to the user.

Think about validation in this case. You are potentially drawing three levels of trust. Your model will require validation to make sure you don't store invalid data; then your service may require some more validation, to ensure that external consumers don't try to do something they're not allowed to do; and your UI will need some validation rules, at best so that it can avoid a postback.

And this is before we even touch the sticky situation of something which should not be allowed through the API but should be allowed through the UI, which requires the API.

I have heard an argument that running your UI through your service is dogfooding and thus good for the quality of the service, but I strongly suggest there are better ways to do that while keeping a solid (and SOLID) separation of concerns between the service, the UI and the business model.

All this said, if you must go the way of wrapping your service with a UI, I would strongly recommend Razor over XSLT.

XSLT is a standard, yes. But XSLT 2.0 still has limited support, so you're stuck with an outdated standard if you want to make that argument.

XSLT is not easy to read. By anyone that isn't an XSLT expert. Who do you think is easier to find, when you need to hire new staff? Someone claiming to be an XSLT expert or an ASP.NET for MVC expert?

And yes, I have seen XSLT used successfully, but only before MVC for ASP.NET was an option.