In order to render something similar to a user control in ASP.NET MVC one creates a partial view – which ends up with the extension of ascx.  This partial view can be embedded into and rendered through other pages (views) . That’s normally done via the RenderPartial method. It all works very well until you need to render a partial view that sits in another folder.Then for whatever reason the system starts to complain bitterly. Yes I know … your supposed to put it into the Shared folder. But somehow that doesnt sit well with my sense of organization. Why have one folder that has a bunch of partials from all over the place.  ( I have not tried adding sub folders to /Shared. Maybe thats an idea as well)

Seems to me that I should be able to create a partial view that has a table of data and then embed this partial view in a variety of other views- wherever I might need this list. And the places where I might need this list could be scattered all over the Views structure.

I am not the only one who ran into issues like this.  Here is a post by a fellow who had similar issues with entire pages.

An internet search turned up the following idea which may possibly do the job:

protected void Application_Start()
{
	var engine = (WebFormViewEngine) ViewEngines.Engines[0];
	engine.MasterLocationFormats = new string[] { "~/Views/{1}/{0}.master", "~/Views/Shared/{0}.master" };
	engine.ViewLocationFormats = new string[] { "~/Views/{1}/{0}.aspx", "~/Views/{1}/{0}.ascx", "~/Views/Shared/{0}.aspx", "~/Views/Shared/{0}.ascx" };
	engine.PartialViewLocationFormats = new string[] { "~/Views/{1}/Partial/{0}.aspx", "~/Views/{1}/Partial/{0}.ascx", "~/Views/Shared/Partial/{0}.aspx", "~/Views/Shared/Partial/{0}.ascx" };
}

Having spent some time with ASP.NET MVC – the revolutionary ” new ” direction of ASP.NET software development I have a few observations:

ASP.NET MVC is more than just the code necessary to make MVC compliant apps in C#. Seriously. It is a lot more. Just as the .NET System.Web namespace put a wrapper around HTML so does ASP.NET MVC.  Its not as deeply permeated as the regular Webform system but there is still an awful lot more to this implementation than simply the code needed to run an MVC app.

Here is the deal – in order to have a plain and simple MVC you don’t need all the stuff provided by ASP.NET MVC.  Basically you need a bit of dependency injection (just a few lines), an Action Framework and Routing Structure. That’s it.

Of course ASP.NET MVC has all that – and I must say the Action Framework is done very nicely – but at the same time it also contains a fullfledged attempt to substitute an entirely new paradigm for the existing webform system. Consequently you have all sorts of wacky stuff going on like Views that look a look like tag soup , partial views that are similar to user controls, a magical way of passing data back and forth among the models, views and controllers and number of other features that are intended to make the system more testable.

I have spent several days so far building an internal test app on the ASP.NET MVC framework and I am here to tell you this is no walk in the park. Considering this is a released product, it strikes me as ironic that there are only a handful sample apps out there which contain any sort of complexity.  There are a handful open source apps out there which range from absolutely pedestrian to entirely new generations of MVC that dont much resemble the MS release version (on the surface anyways)

In addition there seems to be a lot of flux in what is accepted as a good design and architecture. Several of the more prominent samples (Kobe, Oxite, MVC Commerce) are being rewritten based on extensive criticism by the OSS community. This begs the question who is the OSS community and how is it these folks have so much criticism of these products. I really hope its more than the handful of “usual suspects” in the .NET community. You know… the guys that like to congregate around the Alt.Net water cooler.

Here is my issue. When I am learning a new tool Ilook for definitive examples of good design and usage of that tool. And I just don’t see enough of those examples. Having 6 month old sample apps criticized as being incorrect architecture and in need of updates only adds to the frustration levels.

Consider how many millions of ASP.NET programmers there are in the world – heck the Indian sub continent alone can probably account for a few mill – the dearth of good ASP.NET MVC reference material is alarming. One would think that there would be more excitement around this stuff.  Of course I don’t have the same visibility into acceptance rates as some of the MS Regional directors. Its quite a dilemma I think. For almost 10 years MS web technology has gone one way ( web forms) and now here comes this entirely different way of doing it.  Like I said before, I am still waiting to see how ASP.NET 4.0 deals with routing (it still uses web forms). In the meantime I will keep plugging away at MVC.

One thing is for sure, in order for this Revolution to take hold there will need to be a much greater acceptance by the .NET community and that in turn requires more than a handful of books  and a dozen sample apps. In the end I am not even sure that the greater developer community at large will switch to MVC as opposed to Silverlight. Yes MVC will always have its audience , but I am thinking along the lines of the thousands of corporate developers. These guys would have a hard time with yet another paradigm shift and the reward seems to be so much greater in the area of Silverlight apps for these fellows.

I sure hope that in time my posts about this framework will become more positive.  I suppose that once I get past the frustrations there is a lot to like there.

I love the way MVC separates out the code that used to get thrown into the same code behind in web forms. It really shines in that regard. Who knows maybe it will have a positive influence on webforms apps in that regard.

For the moment my bottom line is that it takes a lot longer to write the same functionality in MVC than webforms. That’s partly due to the learning curve and partly due to the fact that there is more code to write. The fact that there is more code will be interesting to watch. Maybe in time people will find some efficient practices that will help to bring down the overall effort required. If thats not the case I wonder how someone would justify the cost of building a system one way versus another. And dont tell me to build it in MVC because webforms are evil. Thats nonesense. We have almost ten years of webform driven sites out there.

Lastly, for all those folks who are jumping on the “Viewstate is evil” bandwagon – which seems to be the same lemmings who jumped on Datasets as a DAO in 2002 – have a look at the following performance test. 6-8 requests per second for an MVC app is laughable. I sure hope that’s not the case presently. Its worth some internal testing to see. By the way, just on a purely subjective note, for the past year I have frequently spent time on MarketWatch. Since they switched to MVC I have noticed a small performance penalty. Purely subjective. Heck maybe its even a matter of browsers.