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 (
- Strongly Typed Html Helpers (which gets back to Data Annotations).
- Using the default model binder (
DefaultModelBinder), which implements
IModelBinder, with Data Annotations. My guess is that explicit use of
IDataErrorInfoeven 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.
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
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â€¦