Razor vs. Find-and-replace for Email Templates

I see a lot of people using the Razor viewer for email templates. At first glance, this seems like a great idea. However, after seeing the letters that most people generate, I cannot help but wonder how to use Razor better than just doing a string-based search and replace.

Most emails get line by line:

<html> <head> <title>Welcome to mysite.com</title> </head> <body> <p>Dear @Model.Name,</p> <p>An account has been created for you.</p> <p>Your account is FREE and allows you to perform bla bla features.</p> <p>To login and complete your profile, please go to:</p> <p><a href="@Model.LogOnUrl">@Model.LogOnUrl</a></p> <p>Your User ID is your email address and password is: @Model.Password</p> </body> </html> 

In this rather trivial letter, why not just do something like:

 string result = template.Replace("@Model.Name", Model.Name); 

I suggest that a further search on the Internet may answer this question, but I have not yet found a solid answer. Is this a strictly performance issue? Or simply these simple letters do not demonstrate the real benefits of using the Razor viewer?

My question here has nothing to do with how to implement such a solution, I understand how to do it. My only question is, is it worth the overhead of using Razor when your emails are so simple? Especially if you use RazorEngine, which accepts string inputs and does not lead to any compiled class for the template.

It seems to me that this is too complicated a decision.

+4
source share
2 answers

Razor lets you later create more complex emails without having to completely redesign your email system.

For example, you can include conventions.

+4
source

This is a matter of performance and semantics. Of course, you can write email templates just by using string replacement, but Razor was originally designed for that very purpose.

In your example, you do a lot of string replacement, which results in a bunch of strings in memory. Even if you switch to StringBuilder to save in memory, you still write code to support your generation of email.

With Razor, you can instead provide a model and keep the actual presentation level outside of your code. Your code is only used to collect email details and then transfer it to another template. It is easier to maintain.

RazorEngine will output a compiled class if you click it. In this sense, this class can be cached and called with incredible performance for templates.

In my opinion, this is like moving from WebForms to MVC; you share your problems and let everyone do their job.

+4
source

All Articles