 |
|||||||||
|
|||||||||
|
|
Before continuing on to read the rest of my post, read Nikhil's blog post.
The MVC framework for ASP.NET has been discussed in a few places, but I think the most well-known location is Scott Guthrie's blog. He's been posting sample code and information on the MVC framework and even had, last time I checked, a link to a video or two showing him discussing the MVC framework with some folks at the Microsoft campus.
There's a couple of things that I like about his sample, and a couple of things that worry me. First, I like the idea that there's an Ajax controller. I hope in the final bits it's simply called Controller and they don't make you distinguish between an Ajax controller and a regular controller - you should be able to pick and choose the functionality you want, and, well, quite frankly, I'm just sick and tired of seeing the word Ajax embedded in code. The Ajax controller should give you, as he demonstrates, the ability to render small bits of HTML. What I dislike about the Ajax nomenclature is that this functionality is useful even outside the realm of Ajax rendering and I think it should be included in the default controller.
Here's what worries me. Ajax, in enterprise applications, is not just about rendering small partial divs dynamically. Sure, that's a big part of it, but by and large when people are using an XML HTTP Request object to hit the server controller for data, they're getting raw data back, they're not usually getting a pre-rendered div. This is often the case when the controller being hit is also providing raw data to smart clients through a REST/POX/web services type of action. So, while I like the notion of RenderPartial for some scenarios, A better example would have been to render a view that outputs simple XML or, even better, JSON.
Another thing that worries me a little about the sample is that it just looks overly complex and klunky. I'll accept the notion that I have to do Ajax.Initialize() or even Ajax.RegisterScript (though, can we please drop the damn Ajax moniker from it and maybe just call it Scripting.Initialize()?? We do remember that it's not actually AjaX unless we're transmitting XML over JavaScript right? Anything else we do in the name of Ajax is just JavaScript).
MVC is all about proper separation of concerns. There's one line of code in the sample that I think is violating that, and that's the IsAjaxRequest property. This all smacks of someone attempting to make the MVC framework feel more like the old Postback world and quite frankly, the old postback world can eat my shorts. The controller, IMHO, is just a controller. It should not ever have to determine if it is rendering Ajax or rendering Regular. Ajax or regular HTML is a view decision not a controller decision. The job of the controller is to fetch the appropriate data required for rendering a view, and then pick the view to render. In my own really personal opinion, I think that the controller should remain agnostic, and if you have JavaScript calling the controller for data, the JavaScript should tweak the HTTP header (e.g. the "Accepts" header) so that the controller knows to render XML, HTML, or JSON. If you have two different kinds of HTML to render, that decision should take place inside the HTML view.
The other thing that bugs me about the IsAjaxRequest property is that it really feels like a postback. For example, is it going to work if the controller that rendered the JavaScript is the CustomerController and the controller being invoked by the XMLHTTPRequest is the OrdersController? I don't know the underlying mechanics of Nikhil's code, but it doesn't look promising.
What I really want to see from Microsoft is a really compelling reason why I shouldn't just take some off-the-shelf Ajax library and make it work with the MVC stuff. I want a really good MVC-compliant Ajax framework that doesn't make me feel like I'm being shoehorned back into the Postback world.
Anyway, it's exciting to see this stuff being worked on in the early stages and it's only going to get better from here.
Another thing I don't like about the new MVC framework is the security
options:
Well, you should also be able to piggyback onto the authentication provider
model so that you can have more fine-grained control over who can do what
in your application. Unfortunately that's going to, from the bits we've
seen in public, require that you write some auth-checking code at the
beginning of each secured controller method.
