0

In other contexts, I'm used to "binding" inferring bidirectional movement of the data to/from the object. Put in other terms, we could call the movement of data from an object to a html form 'serialization' and the reverse, 'deserialization'. However model binders and value providers, seems only responsible for populating an object from an http request - the deserializing part. What part of the pipeline is responsible for taking data from the object and serializing it to the form or other http response? Or does it simply stop with the 'Html.TextBoxFor' utility?

I beleive I could create a custom InputExtension but that seems overkill - the default does most of what I need except for when it grabs the value for a property. I could also create a different model but that is also something I'm trying to avoid.

Is there an extensibility point where I could manage the value extraction from the model to the html input?

b_levitt
  • 7,059
  • 2
  • 41
  • 56
  • Using a reflector, first glance points to a metadata provider? – b_levitt Dec 15 '14 at 16:50
  • Html.TextBoxFor has its trappings and I tend to avoid it; it saves very little typing overall and hides the markup with little value. What is it that you are trying to do? What needs to be done to the property? Is the property of a specific type? Have you considered creating an HtmlHelper extension? – MisterJames Dec 15 '14 at 21:02
  • _the default does most of what I need except for when it grabs the value for a property_? If a property has a value, why would you expect it not to render that value? What is that you are trying to do or what do your expect the result to be? Why would you need a _ custom InputExtension_? –  Dec 15 '14 at 22:40
  • I'm experimenting with an object that has secondary storage. For example an int property would also have a string backing it. If that string was not convertable to an int, the object would be considered to be in an invalid state. In WPF, I have a proxy class of type DynamicObject that intercepts the binding and binds to the backing string rather than typed property. At design time I bind to the actual type for intellesense purposes and at runtime I bind to the dynamic proxy. The problem with MVC, is it balks at the mismatch to the @model declaration so I'm trying to understand my options. – b_levitt Dec 16 '14 at 00:14
  • By the way I appreciate that you're trying to make sure I'm not messing up the pattern, but that's not really what I'm doing here. I have an idea and I just want to see how far I can go with it. Could I just expose a second property? Sure, but what fun would that be? – b_levitt Dec 16 '14 at 00:19

1 Answers1

0

I am typically hesitant when I see questions like this, as there is likely more to the problem than at first glance. Your model likely represents what is stored in the database, meaning that you're needing a translation layer between what is stored and what is displayed. You typically do not want your model displayed as-is to the user, thus the common use of view models when developing on the MVC Framework.

The most commonly used approach here is to:

  1. Use a view model to aid in the rendering of your views, and
  2. Use a mapping layer to move data between the model and the view model
  3. Segregate requests and displays into different view models as they will have different UI concerns

With those pieces in place, you can let model binding happen naturally without having to get into customizing the framework.

A library such as AutoMapper will be your friend. There is a little learning curve, but it's worth it.

MisterJames
  • 3,306
  • 1
  • 30
  • 48
  • 1
    I think your answer would have been better as a comment. I asked a technical question and I'm just looking for a technical answer. Your answer is more about the pattern itself and implies that the pattern addresses my concern without debate which is certainly NOT true: http://stackoverflow.com/a/4071494/852208. – b_levitt Dec 15 '14 at 20:55
  • No, it's not that it's closed to debate by any means, just that this is the most common approach, and given what you've supplied for info in the question, there's no reason it wouldn't work. When you venture into customizing the framework, it's often a "smell" that you might be missing an "already solved" solution. – MisterJames Dec 15 '14 at 20:58