ASP.NET MVC 3 Preview 1 is Released and Catching Up with MVC 2
One indicator of success for me is seeing me complaining about “nothing” to do. Nothing to do means that, say, the release of the ASP.NET MVC 3 Preview 1 would be an exciting event—something for me to jump all over and Blog about on a clean desk with birds chirping on a quiet, verdant day. Nope…
While the new bits are shown on camera on the Microsoft campus, I’m behind, grasping a few known unknowns:
- Data Annotations: supporting display binding, validation and Ruby-on-Rails-like scaffolding (
Html.DisplayFor). - Strongly Typed Html Helpers (which gets back to Data Annotations).
- Using the default model binder (
[DefaultModelBinder](http://msdn.microsoft.com/en-us/library/system.web.mvc.defaultmodelbinder.aspx)), which implements[IModelBinder](http://msdn.microsoft.com/en-us/library/system.web.mvc.imodelbinder.aspx), with Data Annotations. My guess is that explicit use ofIDataErrorInfoeven the need for the PnP Validation Application Block is no longer needed. Stephen Walther: “The Data Annotations validation attributes provide you with a very easy method of performing model-driven validation in an MVC application. For complex validation scenarios, I would recommend taking advantage of the Microsoft Enterprise Validation Application Block. For simple validation scenarios, such as a Movie database application, the Data Annotation validation attributes provide an easier alternative.” For more read David Hayden: “An Aha Moment on MVC Validation Extensibility in DefaultModelBinder—Bye to IDataErrorInfo.” - Developing custom HTML helpers using the MVC source code as a guide. My current gig requires this one.
- Exploring MVCContrib, starting with the DataGrid.
“Fluent HTML?”
Speaking of MVCContrib, there’s an issue that’s older than MVC 2 (and in some ways older than ASP.NET 2.0): in the MVC space this to-do has the title “Fluent HTML.” Tim Scott writes:
I have come to truly hate the overloading approach taken by the out-of-the-box Html helpers. Methods with long signatures are hard to read, and it takes investigation to see what’s happening. What’s worse, you must worry about problems with overload resolution, especially when some parameters are typed as object. As a result, HtmlHelper is not easily extensible. It’s hard to bend it to do new things without breaking existing functionality. We saw an example of this when Beta1 was released with breaking changes. With a fluent interface, it’s much easier to extend with new behaviors while leaving existing behaviors closed.
What some call “fluency” certain folks in the Java world named “method chaining”—not to be confused with “constructor chaining.” And there’s more confusion: many a fashionable developer will use the term “fluent interface” to talk about a pattern that likely shows method chaining. This might suggest that interface-based programming has something to do with fluent design when it does not.
As a jQuery convert—and as a dot-syntax LINQ writer—I do find fluency elegant compared to complex method signatures (even ones with named parameters). As bachelor of physics, my background in Newton’s calculus (not to be confused with Leibniz) leads me to add the word fluxion on to fluent. Recall Newton’s fluents and fluxions?
My only complaint with fluent programming is that the order of method chaining is not easily discoverable. For example the MVCContrib Grid requires Render() or RenderUsing() be called last. What is strange to me is this need for knowing the order of chaining does not bother me when writing LINQ. With the right amount of free time, one could look into this issue. Not yet…