

ASP.NET MVC 3 Preview 1 - Razor View Engine - Halienja
http://www.dotnetcurry.com/ShowArticle.aspx?ID=561

======
keltex
Scott Gu's blog has a much more comprehensive look at this engine:

[http://weblogs.asp.net/scottgu/archive/2010/07/02/introducin...](http://weblogs.asp.net/scottgu/archive/2010/07/02/introducing-
razor.aspx)

~~~
Groxx
_Much_ better, thanks!

------
nck4222
They really needed to do this. The ASPX view engine just felt like they took
existing code and shoved it in to the MVC framework.

A fresh start was needed, and it looks great.

It'll be interesting to see how they incorporate unit testing.

~~~
StrawberryFrog
Views are notoriously hard to test - a lot of that comes down to "does it look
right", which is not automatable.

The MVC pattern is already a lot more unit-testable than most, since the view
is separated from the rest, and data (viewModel) and processing (controller)
can be tested without the view.

~~~
nck4222
I probably should have said that as a reply to the Scott Gu article.

From that article: "Unit Testable: The new view engine implementation will
support the ability to unit test views (without requiring a controller or web-
server, and can be hosted in any unit test project – no special app-domain
required)."

I was wondering how that would work, since as you said, they're notoriously
hard to test.

~~~
hackinthebochs
I think the main point with testable views is that the default asp.net view
engine is completely coupled to the asp.net runtime. It was impossible to
instantiate a view engine instance and render a view inside the test framework
without creating a special app-domain in which to host the test.

I had to wrestle with this just last week, it was a major pain in the ass to
work around this limitation.

------
Mpdreamz
Razor is a major step in the right direction. Spark view engine still offers
enough punch for me not to switch to Razor just yet. The stuff that you can do
with bindings and the convention over configuration stuff are still killer
features for Spark.

------
KirinDave
Am I the only person who sees this and says, “Congratulations guys, nice work!
Now if only you had done this in 2006, you might be on the cutting edge.” I
don't mean to disparage their work, I am sure that is is technically sound and
well-considered.

It seems like, among the leading-edge developers, this kind of tempting is
rapidly being eschewed by newer techniques.

~~~
eds
I cannot understand your last sentence. Please help. "This kind of tempting?"
"Eschewed?" Eclipsed? Eschewed in favor of?

~~~
KirinDave
There is this running gag where I use an ipad on a train and messages get
garbled. Sorry, but its too funny and too late to correct. Try typing
"templating" on an iPad, it will complain.

The correction is, of ourselves, "this kind of templating is being eschewed by
other, newer techniques." Enlive by cgrand is the example I like to mention.

------
tomjen3
The more I see stuff like this, the more I think the lift concept of view
first and XML is better than the MVC model.

------
michalmarko
the new Dynamic View and ViewModel properties is a great addition to mvc3

~~~
traskjd
Why? In particular Dynamic view models? What is the benefit of adding this
third way of expressing your view model objects?

~~~
gokhan
Clearer syntax. No need to define another ViewModel object for each page.
Ability to refactor. Getting rid of naming the param as text.

ViewModel["Something"] = "Other";

vs

ViewModel.Something = "Other";

The best use case for _dynamic_ IMO.

~~~
vyrotek
While I think this is a neat use of _dynamic_ , I think I'm still going to
stick with my strongly typed models.

More specifically, I really like the 'ViewModel' technique. I won't give up my
Intellisense and Compile Time validation anytime soon.

