DD4T with Razor Templating - feasibility

Question

In regular DD4T Page properties and Component fields are exposed as ipage and icomponent. Field values are bound to HTML at run time. But my client claims why we need to construct HTML for every request. Instead if we use Razor Templating, HTML is generated at the Content Manager end, and published to delivery. Hence, HTML generation will be one time activity. Expecting performance will be improved.

My questions here:

1. Considering DD4T is slower then Razor Templating is valid?
2. Can I use Razor Templating and DD4T together (so that I won't loose the advantages of DD4T)?
3. What will be the pros and cons of using Razor Template and DD4T?

Answer 1

If performance is the also concern then pre-generating html is not only option. There could be other options to perform optimization.

1. Perform output caching in the application and if application is public facing then you can look into the option of Akamai caching the page that way entire html will not generated every time.
2. Content caching, so that you don't have to query content delivery every time.

In case, you go with caching approach then you can create deployer extension to clear the cache on publish so that latest published changes are available.

Answer 2

A few rough answers on your questions:

1. Simply considering DD4T is slower then Razor Templating is not a valid statement if you ask me. There will be a lot of questions you need to asnwer before you can make such a statement, for example, are we considering performance over the entire pipeline or just on the web application side? In general a Razor Template will take longer to Publish than the DD4T templates do (so that could make razor even slower), but there is more to consider. Can't just give a simple answer here, depends on a lot of factors too.

2. What exactly do you consider the advantages of DD4T? Be besides that, you cannot combine Razor Templating with DD4T, since DD4T is an MVC approach while Razor Templating generates ASPX pages (or plain HTML if you wish). Keep in mind that for a dynamic website, ASPX pages are often not a good solution, since you run into issues on the IIS side. MVC is a complete different approach, we remove rendering on the CM side, and only render on the web application side. While with Razor Templating it may appear faster for a single page request, you have to consider you are working with a complete different approach, and the performance issues of DD4T can be countered by good caching strategies.

3. What the pros and cons of Razor Templating vs. DD4T are depend on your situation I guess. A few big cons of Razor Templating in general are:

   • Rendering (of templates) on CM at Publish time and at request time on web server (of page) is a hard model to understand and very difficult to correctly debug, increasing TCO
   • When Publishing ASPX pages (Razor Templating), these need to be compiled before they can be served, causing a slowdown of the web server everytime a new Page or change is being Published
   • Publishing ASPX pages (Razor Templating) is not a good approach for dynamic websites, an MVC model (DD4T or DXA) is preferred
   • Razor Templating is not an officially adopted method by SDL, it is considered similar to Dreamweaver Templating and not invested in. DXA (MVC using DD4T) is the suggested approach currently

Answer 3

With either technique you are in some sense "constructing the HTML" for every request. As soon as you make use of, for example, dynamic links, you can't use static HTML any more, and need to have your web application render your page, for example as ASPX. For both "standard" ASPX and an MVC approach using Razor templating, the Page is compiled at first use and thereafter the compiled version is used. With a DD4T approach, you will be retrieving the data from the broker, but if it's set up correctly, most of the time, the data will be retrieved from memory cache.

The bottom line is that for any performance analysis in as complex a situation as a modern web application, there are too many variables to be able to guess which will perform better. You'd need to measure both approaches, and it's quite likely that the most important influences on performance will not be the rendering of the HTML.

In any case, the costs and benefits might not be about which approach performs best in a laboratory test. For example, the business you are supporting may value agility and maintainability, and even if you needed more powerful hardware to achieve the same performance (and as I said, this is not necessarily so) there could be business benefits from investing in an MVC architecture.

Most businesses these days would like to be able to deliver new web functionality in short focussed sprints, with assured levels of quality in the delivered software. Over the years, we've developed various techniques that make automated testing of content manager templates possible, but it's never been a comfortable fit. Moving your templating to the web application allows you to use mainstream industry techniques for unit testing and the like.

Testing is just one example that shows how the trade-offs between architectures end up being about more than simply the speed of rendering your HTML. The rendering speed will most likely be fine in any case, but you should probably also be focussing your thoughts in other areas.

Answer 4

The main purpose of using DD4T is to help with MVC based implementation.

If the requirement is to generate html on content manager side then using DD4T will not help.

You probably want to look into dreamweaver templating or razor templating in which html markup generated during the publish time so final rendered output on content delivery will be html.