I'm working on an ASP.NET MVC project. I have a form that is strongly typed. Is it considered good practice to add serialisation attributes to the same view model to control how the data is serialized once it is posted to the server. For example, I have many properties that are strictly used to show/hide UI components. Can I add [XmlIgnoreAttribute] to each of these properties in the view model so they won't be serialised or is it better to create a completely difficult class for serialization.
closed as primarily opinion-based by user22815, user53019, Ixrec Dec 4 '15 at 7:49
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
Conceptually, consider viewing and updating. They're very different things. Using a distinct ViewModel and UpdateModel is sensible. The ViewModel contains everything the view needs to do its job (that it doesn't already have). As such, it might contain select options, background colors, image paths... who knows? When you update the data from the ViewModel, it doesn't make much sense to pass those properties along.
As you mention, one option is to fuss with bindings so you don't get the unneeded data. That leaves me cold, however. I'd much rather see an action parameter that does exactly what it means. An explicit UpdateModel does the trick. Sometimes, you can simply recycle a domain model. If the data coming back from the UI is a little trickier (maybe it maps to more than one domain model), a separate UpdateModel serves you well.
Keep in mind, this isn't necessarily a common practice from what I see in the field. Using that same criteria, however, I'd note that brushing your teeth after meals also appears to be an uncommon practice and I'm not giving that up any time soon.