ASP.NET MVC 2

Jeffrey Richardson — Mon, 17 Aug 2009 17:03:14 GMT

ASP.NET MVC 2 has been announced with the release of ASP.NET MVC 2 Preview 1. After having read through the rather lengthy overview of new features written by Scott Guthrie. Many new great features have been listed, but the two that tend to stand out the most is support for areas by project and template helpers for editing and displaying data.

Project based areas seemed to be an official solution to my categories dilemma. On further inspection, it becomes apparent that the projects are not logical containers to an area. The areas implementation is still the original namespace based one, with the projects allowing simple tooling support to keep a consistent namespaces in a defined area, as well as some behind the scene build tasks that allow all content to be merged together. However, it does appear though that this has lead to some internal support of areas in general, making my category implementation integration more seamless.

Template helpers appear to be very useful. I already have a few ideas for including designer (quick preview) support for these, utilizing a control designed to provide similar functionality to the Editor/EditorFor and Display/DisplayFor. These methods return a string, and are used similar to how other HtmlHelper methods are used, such that it could be assumed that the return value would be the markup to send to the client. Looking into the code, however, shows that these methods return an empty string, while using the ResponseContext to write the markup directly to the response stream. I believe it’s safe to assume that this was probably a quick port to show off the functionality, and later will return the markup rather than write it.

One bit of annoyance with regard to extending ASP.NET MVC is that the most useful classes tend to be set internal, such as InputHelper and TemplateHelper. This makes it difficult to integrate at certain levels, especially in cases where the extensions have already done the work the public interface does or doesn’t need to do the work. This creates a larger problem in the case the public interface is much more limiting than what the extension is trying to offer. This situation tends to leave three less than ideal solutions: building the extension directly into the assembly, which requires the entire assembly distributed as standalone, not allowing integration with other some other extensions, including the relevant source directly in the extension, which causes updating to be more difficult, as well as ensuring internal dependencies, or creating a wrapper which reflects the code, which requires much higher privileges, and can’t run medium trust as a result.

There are a few new features that leave more to be desired. However, this release, as well as the future planned releases appear to be a great step forward in this technology, to which I look forward to more information.

Templates

ASP.NET MVC 2