Microsoft

On ASP.Net MVC (yes, again :-))

Ayende Rahien — Wed, 12 Nov 2008 19:40:31 GMT

As you probably know by now, I have been working on an ASP.Net MVC project for the last two weeks. Based on that, I think that I can base a pretty good opinion about it.

Are you ready for it?

[insert significant pause here]

I like it.

Now, just to be clear. I like it not only in comparison to WebForms. I like it on its own. In other words, I don't consider the ASP.Net MVC to be a default choice if all you have is that or WebForms.

The pros of using an MVC framework are well known by now, so I wouldn't go blathering about that. ASP.Net MVC certainly hits a lot of those points. Another benefit that wasn't obvious to me was the default view engine, which uses the same WebForms editor. This means that we get intellisense. That was surprisingly nice to have.

Unfortunately, the WebForms view engine is also useless for any intermediate to advance scenarios, because it only allows you to render directly to the response, and doesn't allow you to capture the output of views and partials and process them further.

Another problem that I encountered with the framework is that, to someone who has been doing MVC for years, is it extremely non obvious at times. My default mode of learning is to dive into the code, and in general, this has been a successful way of doing things across many projects that I learned. I don't really like it that I run into brick walls along the way with ASP.Net MVC, but I should point out that my thinking about how things should work is based on my work with MonoRail, and it is likely affecting my expectation about the way the ASP.Net MVC behaves. Even so, there are several design decisions made there that I strongly disagree with.

The most problematic issue that I run into with the ASP.Net MVC during the last too weeks, and the reason that I don't consider the ASP.Net MVC vs. MonoRail to be a coin toss, is that a lot of the code is internal.

Now, I didn't actually went over the ASP.Net MVC source code. But I did tried to do things with it and was blocked several times because some of the things that I wanted to do are internal (IBuildManager comes to mind as a repeated example). The obsession with internal, and the resulting limitations of what I can do with the framework, is a huge problem for me in just about any Microsoft product. In this project, I explicitly didn't set out to create any complex site. I built a very trivial data driven CMS. Nevertheless, I hit a lot of those internal API, grr!

Most of those occur when trying to do anything interesting with the web forms view engine. There is enough friction using that that is it worth dropping it (web forms view engine) all together, even with the bonus of having intellisense in the views.

From the point of view of actual framework, I found it pleasant to work with for most of the time. And the extensions points that are open are very useful (OnActionExecuting, OnActionExecuted are good example of that). I think that in order to really get the benefits of the framework, I am going to have follow Jeremy Miller's footsteps and rip out all the thinks that I don't care about and replace them with a heavily opinionated and customized version.

The good news is that it is possible, and without too much problem.

And yet ANOTHER ASP.Net MVC Bug

Ayende Rahien — Tue, 11 Nov 2008 20:31:44 GMT

This is getting annoying, to tell you the truth. I am trying to develop an application here, not do QA.

Let us take the following class:

public class IdAndName
{
    public long Id { get; set; }
    public string Name { get; set; }
}

And the following code:

var idAndNames = new[]
{
    new IdAndName {Id = 1, Name = "one"},
    new IdAndName {Id = 2, Name = "two"}
};
var list2 = new SelectList(idAndNames, "Id", "Name", idAndNames[1]);
var result2 = Html.DropDownList("test",list2);

What would you expect the value of result2 to be? I would expect it to render a <select> with two items, the second of which should be selected. Here it what it is generating:

<select id="test" name="test">
	<option value="1">one</option>
	<option value="2">two</option>
</select>

Notice that there is no selected attribute on the second one.

I will suffice with GRRRRRRRRRR!!!!! at this point.

Another ASP.Net MVC bug: Rendering views to different output source

Ayende Rahien — Tue, 11 Nov 2008 20:29:41 GMT

Take a look at the following code. What would you expect the result of this code to be?

Leaving aside the question of exactly what I am doing here, or why. What I thought this should do was to render the partial view into the string writer.

The method signature of Render most strongly suggest that this is what it would do. What it actually does is to render the partial view directly into the response. Following the code a bit more, it looks like you literally cannot do this.

ASP.Net MVC views are hard coded to use the current request ( ViewPage.RenderView ). I checked a bit, and without basically faking the entire HttpContext and all its associated objects, that doesn't seem to be happening.

There are two problems here:

The API lies about what it is doing
There is no simple & obvious way to get the output of a view except directly into the response.

Reproducing a bug

Ayende Rahien — Fri, 07 Nov 2008 16:29:46 GMT

Create new ASP.Net MVC application:

Create an action that take non nullable argument called 'id':

[HandleError]
public class HomeController : Controller
{
    public ActionResult Index()
    {
        ViewData["Title"] = "Home Page";
        ViewData["Message"] = "Welcome to ASP.NET MVC!";

        return View();
    }

    public ActionResult Test(int id)
    {
        return Content(id.ToString());
    }

    public ActionResult About()
    {
        ViewData["Title"] = "About Page";

        return View();
    }
}

Go to home/index.aspx and add the following before the final </asp:Content> tag:

    <% using(Html.BeginForm("Test","Home")){ %>
        <%=Html.Hidden("id",2) %>
        <input type="submit" value="test" />
    <%} %>

Visit the site and see that you indeed have a test button on the page. Click the button.

Get an exception:

I am going to assume this is a bug.

This is on the ASP.Net MVC beta bits.

Title left blank since I can't think of non inflammatory title for this post

Ayende Rahien — Fri, 07 Nov 2008 15:35:36 GMT

This works:

This doesn't:

I haven't bothered to find why, but that is surprising to me. (Note that here the enctype is specified as "multipart/form-data", which may or may not be related)

Update: It is not related.

The real culprit, as best I was able to reconstruct is because of this piece of code:

public static void RegisterRoutes(RouteCollection routes)
{
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

    routes.MapRoute(
        "Default", 
        "{controller}/{action}/{id}", 
        new {controller = "Home", action = "Index", id = String.Empty} 
        );
}

It looks fairly innocuous, doesn't it?

Except that this means that when ASP.Net MVC looks for a matching value for the "id" parameter, it will only look in the route parameters, and not look at the request parameters.

I found this surprising, to say the least.

A case study of bad API design: ASP.Net MVC Routing

Ayende Rahien — Wed, 05 Nov 2008 19:16:08 GMT

I am doing a spike in ASP.Net MVC now (and I'll talk about this at length at another time). I hit the wall when I wanted to do something that is trivially simple in MonoRail, limit a routing parameter to be a valid integer.

Luckily, just looking at the API signature told me that this is a supported scenario:

Unfortunately, that is all that it told me. This method accept an object. And there is no hint of documentation to explain what I am suppose to do with it. A bit of thinking suggested that I am probably supposed to pass an anonymous type with the key as the route parameter and the value is some sort of a constraint. But what sort of a constraint.

Type information is one of those things that static language actually do, and from experience in both dynamic and static languages, while it is often a PITA to specify types, it actually help for people who read the code. Not often, I'll admit, but it is helpful for the uninitiated.

I am... unused to having this type of problem in C#.

So I did what any developer would do, hit google and tried to find some information about it. Didn't work.

I pulled reflector and started to track down what is going on there. Following a maze of untyped paths that I have not seen the like since the 1.1 days, I finally figured out that the value that I need to push is an instance of IRouteConstraint.

Obvious, isn't it?

In short, and the reason of this post. I am seeing a lot of parameter signatures that look like that, and have barely defined semantics. I would file this under C#.Abuse();

PhizzPop fizzed out

Ayende Rahien — Wed, 05 Nov 2008 14:11:41 GMT

Yesterday I was at the PhizzPop design party in New York. The purpose of the party was to show off the capabilities of the new Expression 2.0 product line. The way chosen to do so was by getting several companies to participate in a content to get the best result. It might have been a good idea, but it back fired tremendously.

One of the reasons that I went to that party was the expectation that I would be impressed by the new capabilities. Instead, what I saw there was... disappointing.

The best candidate application there was adequate. In fact, it was pretty good, but not nearly good enough to take part in a design contest. It is bad when I, a developer with negative UI sense, can spot problematic UI and see how they had to fight with the platform to get it to do things.

And that was the best they had. One of the other application (in a design contest!) had a RadioButton1, RadioButton2 and other things like that showing. They could literally not be bothered to change something as basic as that.

I was very disappointed, and the impression that I got from the entries in the contest is that the platform is a really lousy one. Especially considering the amount of time that was supposedly invested on the entries.

To conclude, I want to quote myself: "I know of people who can do better and faster than that drunk, and while writing the XAML on a stone tablet with a chisel."

Very disappointing.

Visual Studio 2010

Ayende Rahien — Mon, 27 Oct 2008 10:48:14 GMT

I got the chance to get an early CTP of Visual Studio 2010.

This is the post I use to record my first impressions. There is no order to this post, it is just impressions jotted down as I see them.

We seem to have a new start page:

Following the MS & OSS new approach, one of the samples is Dinner Now using Lucene, which is the first project that I found to test.

TFS is still broken:

I really don't like to see this kind of issues in a source control system. It means that it cannot be trusted.

Looks like we have something new here. On first impression, it looks like we have UML integrated into VS.

I took a look at the generated XML, which is the backing store for the diagrams, and it looks like it should work with source control much better than the usual modeling stuff in visual studio.

Another feature that is very welcome for anyone doing presentations is the use of CTRL+Scroll Wheel for zooming.

We are also promised performance improvements for large files, which is nice. Part of the walkthroughs talk about integrating functionality using MEF, which is good.

Looking at the walkthrough for creating syntax highlighting, tagging and intellisense, it looks like a lot of ceremony still, but it seems significantly easier than before.

WPF - It looks like VS is moving to WPF, although this CTP is still midway.

C# has dynamic variables!

dynamic doc = HtmlPage.Document.AsDynamic();
dynamic win = HtmlPage.Window.AsDynamic();

This was talked about in the MVP Summit, a dynamic object is an object that implements IDynamicObject:

Note that we accept an expression parameter (using Linq expressions) and we return a meta object. Show below.

This looks like C# + DLR integration, which is cool. I am looking forward to see what we can do with it.

VS also get some R# like features:

There is also a quick search, apparently, but I am not really impressed. Again, show me something that I don't have.

There is CLR 4.0, so we somehow skipped CLR 3.0. I am glad to know that we have a new runtime version, instead of just patching the 2.0 very slowly.

Threading

System.Threading.Tasks is new, and looks to be very interesting. It also seem to have integration with Visual Studio. It is also interesting because we seem to have a lot more control over that than we traditionally had in the ThreadPoll.

Parallel extensions are also in as part of the framework, not that this would be a big surprise to anyone.

In the CTP that I have, there is nothing about Oslo, models or DSL, which I found disappointing. I guess I'll have to wait a bit more to figure out what is going on.

That was a quick review, and I must admit that I haven't dug deep, but the most important IDE feature, from my perspective, is the CTRL+Scroll wheel zooming. The diagrams support is nice, but I am not sure that I like it in my IDE. Threading enhancements are going to be cool, and I am looking forward to seeing what kind of dynamic meta programming we can do with it.

On jQuery & Microsoft

Ayende Rahien — Mon, 29 Sep 2008 06:44:27 GMT

No, I am not going to bore you with another repetition of the news. Yeah, Microsoft is going to bundle jQuery with Visual Studio and the ASP.Net MVC. That is important, but not quite as important as something else that I didn't see other people pointing out.

This is the first time in a long time that I have seen Microsoft incorporating an Open Source project into their product line.

I am both thrilled and shocked.

The Managed Extensibility Framework

Ayende Rahien — Thu, 25 Sep 2008 17:10:22 GMT

The Managed Extensibility Framework is "new library in .NET that enables greater reuse of applications and components. Using MEF, .NET applications can make the shift from being statically compiled to dynamically composed. If you are building extensible applications, extensible frameworks and application extensions, then MEF is for you."

(I was too lazy to think about my own description for it, so I just copied the official one.)

Probably the first thing that you should know about MEF is what will undoubtedly be the most common cause for confusion.

The Managed Extensibility Framework is not an IoC container.

This is not a slug at MEF, it is an important distinction. If you try to judge MEF through IoC container glasses, you will come away confused. It may walk like a duck, but it meows.

MEF is, first and foremost, a composition framework. And its target audience are BIG applications. Those two, taken together, are important to understand what MEF is and how we should look at it.

What is the difference between a composition framework and an IoC container? On the surface, they are doing much of the same thing, managing dependencies for the application in an automated fashion. The difference (and the devil) are in the details.

IoC containers have long ago stopped just managing dependencies. They are taking care of a lot of additional responsibilities. Managing lifecycles, proxies, aspect orientation, event aggregation, transaction semantics and a lot of other features.

In addition to that, there is a lot of focus on problem solving by utilizing the container. Things like generic specialization or component selectors allows you to approach a lot of very complex problems in a completely different mindset.

A composition framework, on the other hand, is focused on a single goal: dependency management.

It sounds like MEF is a subset of what an IoC container is doing, I know. This is not the case. MEF, the bits we have right now, are doing a lot more in the area of dependency management than the containers are doing. Where a container is usually static and opaque, MEF primary focus is to make the dependency management itself a dynamic and transparent process.

This is where the second part of the MEF design goals come into place. MEF is targeting Big applications. The really big ones. One of the immediate customers of MEF is Visual Studio itself.

Things like ( take a deep breath ):

being able to query meta data without loading assemblies
statically verify the dependency graph for all the components and reject those that would put the system in in valid state
being explicit by default
contract adapters
discovery
metadata tagging

All of those are key concepts in the overall dependency management theme. And all of those are the product of having a Visual Studio being one of the first consumers of this project. Visual Studio needs this kind of things, across tens of thousands of components. And MEF is setup to handle those kind of scenarios.

So, MEF is very similar to IoC containers, but it has very different goals (or maybe it would be more accurate to say that it has very different priorities).

Another important aspect of MEF has nothing to do with it at all and everything to do with where it is going to be used. MEF is going to ship with .Net 4.0, which put it in a position to be very widely distributed, but more importantly, since it is on the framework, it can be used by other parts of the framework. Which is where it get interesting.

There are a lot of places in the framework that could make use of a container. IControllerFactory is a good example of something that should not exists, for example. I am ambivalent with regards to that, because I think that the correct abstraction for those kind of things is not necessarily MEF, but that is beside the point.

And that is enough for now, I am going to toss a coin and see if it is going to be Erlang code or meta documentation next.