Model binder

[JoseFR]

Hi, first of all thank you for this great work.

I have a doubt with the Model Binder concept...I understood that if I
have a class:

Customer:
int Id
string Name


and put the same names to the form controls of the view, my Action
method can take customer as their parameters.

Now, suppose to have a class:

Product
int Id
string Nombre
Category Category

Category is a many to one relation.. My view have a "select" called
Product.Category, with the list of available categories. I think the
default modelbinder will not be capable of set the Category property,
because I has to use the Category Repositorie....
What will be the best choice for this case?

a-Create a custom modelbinder with a reference to the
CategoryRepository (or ICategoryRepository)...
b-Use HttpContext.Request.Form["Product.Category"] in the controller
Action.

any other options!?



Thanks in advance.

[Billy]

Personally, I think the automatic model binding options which come
with MVC are very lacking. They're only useful in the most simplistic
of situations. I'm looking at various approaches to creating a S#arp
Architecture custom binder which would leverage the fact that a
project is using S#arp Architecture to automate binding in a much more
powerful manner.

Billy

On Feb 24, 7:43 am, JoseFR <jfromanie...@gmail.com> wrote:
> Hi, first of all thank you for this great work.
>

> I have a doubt with theModelBinderconcept...I understood that if I

[Ramana Kumar]

I do not have any experiece on this component... but have you looked at http://www.codeplex.com/AutoMapper?  If this is the type of mapping capabilities that you are looking for, then could this be used to do the heavy lifting in bi-directionaly map from Text field to the (nested) object property?  You could then implement and register it as your generic Model Binder.

 

Just a thought.

Ramana

[JoseFR]

Billy; sounds great.

Ramana Kumar; Probabily will be a interesting idea. But, following my
case Category have other propertys, not only ID, that the Product_Add
view doesn't know about. For the other hand, will be needed "re-
attach" the category object to the nhibernate session.

From my point of view, its not so usefull to write a modelbinder for
an especific entity if you will use once. So I think that A is not a
very good idea for most of the cases.


On Feb 25, 9:50 pm, Ramana Kumar <ramana.r.ku...@gmail.com> wrote:
> I do not have any experiece on this component... but have you looked athttp://www.codeplex.com/AutoMapper? If this is the type of mapping

> capabilities that you are looking for, then could this be used to do the
> heavy lifting in bi-directionaly map from Text field to the (nested) object
> property?  You could then implement and register it as your generic Model
> Binder.
>
> Just a thought.
> Ramana
>

[sfradel]

I have to agree that default model binding is appropriate only for
simple scenarios.

With complex objects I desided to go with custom model binders in
order to fill the gap. But doing so leads
to use repositories inside the model binders (JoseFR option a) with
the help of service locator which i do not like.

If i understood well automatic model binder is a model binder that
automaticaly uses repositories to wireup
entities?.

Billy I would like to see an example (if possible) of how NH entities
could be populated from
complex input form data (dropdownlists, list of other elements etc).

[Billy]

sfradel,

You bring up a valid concern with respect to the binder being forced
to use a service locator to find the appropriate repositories to
support a variety of binding scenarios. But on the other hand, I find
myself spending a considerable portion of my time doing binding logic
between the form and the model. Sure, I could use a form-specific DTO
to bind everything in one quick go, but I still have to worry about
associations, proper handling of collection updates, etc. I'm
thinking that a sufficiently powerful binder, with full access to
repositories via the service locator, would be a huge time saver to
this "administrative" development overhead and worth the inclusion.

Billy