I have to admit that ASP.NET MVC is cool.  The ability to interleave UI elements with control flow statements makes things a lot easier than the traditional databinding of ASP.NET.  The ability to pass strongly-typed objects to methods and auto-magically have pages appear with the data without ugly hacks is just awesome.  The new Razor engine in MVC 3 takes this to an entirely new level with its much simplified, less ASP-like syntax.

But there is a problem in MVC land.  We’re building UIs so why can’t I visually see what my page is going to look like within the designer?  It brings back memories of the ASP/HTML days where you’d write your UI and then run IE to see what it looks like.  From a UI designer perspective this is insane.  One of the really big features of ASP.NET (and perhaps Visual Interdev) was that I could write my UI and then switch over and view it without leaving VS.  I could even drag and drop controls onto the form and voila I could make changes until it is just right.  No such ability in MVC.

Pundits generally justify this lack of functionality in MVC in one of the following ways:

• It’s MVC, you don’t care about the view layout since you’ll use CSS to format it – Bull.  CSS controls basic layout, coloring, fonts, etc but there is absolutely no way to verify how your view and CSS play together without actually running it.  One of the big “advantages” of MVC is that we are suppose to be able to pass our view on to a UI author but how many authors do you know that could read MVC blocks and understand them.  It isn’t simply a matter of ignoring the blocks because those blocks control what gets generated when.  So a UI author has to understand MVC just to write the view.  All we’ve accomplished here is to move the complexity from our code to the UI.
• MVC has extensible view engines so a VS designer would have to support them – So?  IIS renders the various webpages without regard for the underlying rendering engine.  VS itself is designer agnostic.  How hard is it to create a separate designer for each of the view engines that can then be invoked within VS just like in ASP.NET?  All it really takes is some prioritizing.  A UI designer seems pretty important for a UI technology.  Even more so then some of the other features that have been added into MVC.
• Browsers render things differently so the designer might be wrong – That is true but didn’t ASP.NET have the same issue?  Technically though one of the big benefits of MVC is that most of the view is browser-agnostic.  The various support files are there to help ensure that it renders the same across all browsers.  What better way to test this functionality then by using VS as a testbed?
• It would just be too difficult – I bet they said the same thing before ASP.NET came out.  I don’t believe there is any technical problem that cannot be resolved.  ASP.NET, in my opinion, is the harder technology to design for since it is so monolithic and structured so it seems that MVC should be easier to create a designer for.
• Use ASP.NET for your UI and MVC for everything else if it is such a big deal – What?  That would be like C# not supporting integers and the justification being that you can just use Fortran for the math.  Mixing and matching equivalent technologies, while useful when necessary, should be avoided.  It complicates the project, requires more skills from the dev team and can cause interop issues. 

Here’s my solution – add full UI designer support for MVC!!!  How hard can it be to invoke the correct view engine in the VS designer?  MVC view engines are far less heavy than ASP.NET so it seems like a relatively easy task.  Since ASP.NET is already supported the infrastructure needed to host a web-based engine is there.  It just needs to be tweaked to allow MVC engines to run.  Even if we cannot guarantee that a page will look exactly the same when rendered in a browser it would at least give us a better idea of how it might look.  The ASP.NET designer supports loading the CSS correctly so an MVC engine should be able to render pretty close to what we’d expect.

To me the lack of a UI designer (IE doesn’t count) is a really big mark against using MVC in a project.  I started using MVC in a couple of projects but since most web apps are UI-heavy I had to back away.  It was simply to painful trying to build the UI in an MVC-friendly manner.  The whole concept of MVC is great.  I just can’t understand why the V part of MVC is so difficult.  After all isn’t the entire purpose of MVC to allow us to separate M, V and C to simplify development?  It’s really ironic.  They say history repeats itself and I agree.  We started with HTML, moved on to ASP, then to ASP.NET and now we’re back to MVC.  UI designer wise we’ve come full circle.  Perhaps the next great framework innovation will take all the great things of MVC and combine it with a usable designer so we can actually get our work done.  Just my opinion