There's a question that was recently asked found here: How can I bind a C# WPF TextBox to different properties depending on a condition?

The question asks about bindings in WPF but makes no mention of MVVM or a ViewModel class. Someone answered

You could do the behind in the callback of the event Checked of your radiobutton..

Something like :

Binding b = new Binding("ShippingAddress"); _textBox.SetBinding(TextBox.TextProperty, b);

Which is technically correct, but HighCore's kind of throwing a fit over the fact that bindings are being done in the code-behind when they should, ideally, be done in a ViewModel class, adhering to the MVVM pattern.

In cases like this, should we submit answers involving use of the MVVM pattern even though the user might not have MVVM implemented (as HighCore did), recommend they implement the MVVM pattern, or answer the question as it is (as franssu did)?

I'm in agreement with HighCore that bindings really should be done in a ViewModel, but I don't think it's proper to throw a fit about it when that's not what OP was asking for and the answer submitted does fulfill OP's question.

Edit: I am rescinding my above comments. Should I down-vote an answer that works but promotes bad practices? Given the situation, HighCore's behavior was warrantable. Franssu's answer is viable but promotes bad practices.

  • 1
  • @user814064 Okay, I'll rescind my comments. Given the situation, HighCore's behavior was warrantable as franssu's answer does promote bad practices. – DanteTheEgregore Sep 13 '13 at 16:06
  • @ZachSmith I'd just like to take a second to mention that HighCore, in the past, has not made such comments in a positive tone and in a constructive manor. While suggesting a more significant design change rather than a quick fix can be appropriate, it should still be done politely, without being insulting or non-constructive in your comments. – Servy Sep 13 '13 at 16:22
  • but HighCore's kind of throwing a fit over the fact that bindings are being done in the code-behind when they should, ideally, be done in a ViewModel class, adhering to the MVVM pattern. lol bullshiz. Nothing wrong with UI tasks being handled in the codebehind. I'd just ignore him. – user1228 Sep 13 '13 at 19:22

Either answer is allowable, if it is a possible solution for the OP to use to solve their problem.

If they have specified in the question itself that a particular avenue is not an option, i.e. they have explicitly sated that they cannot do the task a particular way, or that there is some constraint forcing them to do, whatever, then you should honor those restrictions and not propose solutions that violate those constraints.

Keep in mind that readers are free to vote however they wish. If the feel that an answer that directly answers the question would result in irresponsible or inappropriate code, they may choose to downvote your answer, even if it works, and upvote a solution that would involve a bit more involved of a change, but that is a superior overall design. Conversely, an answer that suggests an unnecessary or inappropriate paradigm shift when a reader feels that a direct and specific answer would be easier and appropriate may result in the more involved suggestion being downvoted. This is one of those problems that is somewhat of a judgement call and it's important to consider, in context, what you think is going to be best.

It is this voting, based on what the community feels is best, that lets the best answers float to the top. An answer that suggests a more significant change shouldn't be deleted for that reason alone, nor should it be downvoted without consideration of whether it's appropriate. At the end of the day, if you consider the post to be helpful you should upvote it, if you feel that it is harmful (whether it works or not) you should downvote it.

| improve this answer | |

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .