Previews, Previews, and more Previews.

Love 'em… but it is hard to see the big roadmap sometimes.

We've been furiously pumping out new business logic and the code to expose it via our new friend: the ASP.NET MVC framework.

Keeping up with the previews is a lot of work on its own… but I think that's a good thing! (it shows how furious the MVC team is working).  Read the blogs… any tech docs I can find… the forums… and only god knows how many hours I've logged in reflector.

I have MANY questions about the future of MVC that continue to remain a mystery. If my extensive web searching doesn't yield results, I turn here-although I haven't had a lot of success getting the replies to come in whether it is a simple question or a more advanced topic. Perhaps the answer is simply "we don't know yet" … or (is hard to resist the thought) that Microsoft is withholding these answers for business and/or legal reasons.  Don't worry, I'm not bitter over that possibility-I am a strong advocate for wise business/legal decisions. :)

Yet, I'll post more and hope for the best.

ModelBinders
Great idea… but I'm not sure they are in the right place (System.Web.Mvc). It seems to me that binding and validating user input is more of a core concept rather than MVC (or any web technology) specific. Models could certainly use this kind of binding and validating in WinForms and WCF. I just hope this doesn't end up like the JavascriptSerializer vs. DataContractJsonSerializer.
One of my (rough) general rules I have for keeping code in its proper assembly is this: If something requires me to reference System.Web* in one of my core assemblies, I'm doing something wrong. I would like to keep the binders close to my Models (which are in a core assembly) because of the reason in the previous paragraph… however, currently I'd have to break my rule to do so. Sooo, my Binders are in my Web assembly. I'm Ok with it for now, since this is all "preview" code… but can anyone tell me what the bigger roadmap is for these?

FormCollection
Why pass it in to the action? Can't the Controller class just expose it as a property? It could probably just be lazy loaded if nothing else… and it would still be testable.

System.Web.Abstractions
Much needed. I'm SOOooo excited. But I want to know: will these get pushed under the existing ASP.NET framework someday? Looking at how they've been setup, it seems like they might be considering this. (IE: all the abstract classes with wrappers)

…Ok, that's enough for now.

Maybe I just haven't stumbled on the right blogs or used the right query terms in my google.. aheerrm.. I mean Live searches yet. ;)

SO, please share your thoughts…

theozco,

You make some good points.  I am not sure if you are looking for a direct response for the team or just general discussion, but I am up for discussion so here it goes.

Model Binders

Aren't the model binders inherently tied to the System.Web.* namespace because they depend on the Form/Request infrastructure.  I think of WinForms as a totally different beast when it comes to capturing input and validation and it already has a binding framework.  As for WCF, I could be ignorant here, but as far as I know WCF isn't a UI framework and therefore you shouldn't have to worry about validating input in the same way.  I am not saying that you don't have to validate input, but the data should already be in the correct data type and such.

FormCollection

I am curious.. If the question was rephrased "Why not pass it into the action?" how would you respond?  Also, I don't believe this is mandatory.

System.Web.Abstractions

I believe Phil Haack has stated on his blog, that it is the end-goal to get these (and other changes to make the framework more testable) included in the base ASP.NET Framework.  Because they are working "out of band", they can't change the base Framework right now, so they are creating wrappers and sticking them in the System.Web.Abstractions namespace.

Thanks for your thoughts...

bradleylandis:

Model Binders

Aren't the model binders inherently tied to the System.Web.* namespace because they depend on the Form/Request infrastructure.  I think of WinForms as a totally different beast when it comes to capturing input and validation and it already has a binding framework.  As for WCF, I could be ignorant here, but as far as I know WCF isn't a UI framework and therefore you shouldn't have to worry about validating input in the same way.  I am not saying that you don't have to validate input, but the data should already be in the correct data type and such.

With the current implementation of of the ModelBinders, yes- they are tied to the Form/Request. My ramblings were aiming about abstracting this to a higher level where the thought is "We have inputs from somewhere that need to translate in to our models and validate them in the process." Yes, in ASP.NET we have Request.Params that we're translating- however just the same, I can have WCF [DataMethod]'s that translates inputs in to my Models.
...I guess I'm just hoping for soem kind of unification of these translations.

bradleylandis:

FormCollection

I am curious.. If the question was rephrased "Why not pass it into the action?" how would you respond?  Also, I don't believe this is mandatory.

Just so I don't have to add a "FormCollection form" parameters to all of my actions. The DRY (don't repeat yourself) idea.

 

bradleylandis:

I am not sure if you are looking for a direct response for the team or just general discussion

 

Perhaps both...?

Which ever it was... your reply is just what I'm looking for :)

-William Kapke

Model Binders

I like the concept of a "unified" approach, but I fear if you abstract it any further it would be completely abstract and not adding any value.  I think at that point you are more into Design Patterns rather than an implementation in the framework.  For example, for validation I am using the Notification Pattern outlined by Martin Fowler with great success and it integrates nicely with the Model Binder/Model State framework in ASP.NET MVC as well the standard binding framework in WinForms.

FormCollection

I am all for keeping things DRY but I don't think passing in the parameter really violates this.  And like I said, as far as I know, this is completely optional.  I believe there are at least 4 ways of getting at the form data in your action (individiual parameters into your action, grabbing them from Request.Form inside your action, Model Binders and FormCollection).  So you can have a standard for your application or pick and choose based on the contents of the action. But you certainly shouldn't "have" to add this parameter to all your actions.

theozco:

With the current implementation of of the ModelBinders, yes- they are tied to the Form/Request. My ramblings were aiming about abstracting this to a higher level where the thought is "We have inputs from somewhere that need to translate in to our models and validate them in the process." Yes, in ASP.NET we have Request.Params that we're translating- however just the same, I can have WCF [DataMethod]'s that translates inputs in to my Models.
...I guess I'm just hoping for soem kind of unification of these translations.

Scott Gutherie may have hinted to an answer on this one in his blog post today:

scottgu:

We are currently investigating a few ways to enable this - including adding support for the IDataErrorInfo interface, as well as support for the new Dynamic Data attributes in the System.ComponentModel.DataAnnotations namespace.