2

I'm interested in approaches that avoids code in the code behind. In my opinion, there are some cases where code must be placed in the code behind. For example: I have a grid with an undefined count of columns. Columns can't be binded. So the easiest way would be to generate the columns in the code behind.

For this case, I can create a new class which inherits from the grid. This new class has a new binding property and code for the column binding. The code is separated in a custom class which can be used in the XAML. And then, I can easy bind the columns to my newly created property. And the view has no code behind.

Is it a good idea? How would you solve such (or similar) problems? Are there other ways to extract the code from the code behind?

Thanks.

Improve this question
8
  • You should use whichever tool makes the task simple. There's nothing at all wrong with writing code... seriously. Commented Sep 1, 2012 at 19:38
  • In my opinion.. it IS! When I decided to work with MVVM I don't want to mix. Only code behind.... or only mvvm.. but no mix. I think this is important. Commented Sep 1, 2012 at 19:45
  • Why do you think that is important? Commented Sep 1, 2012 at 19:51
  • 1
    Code-behind has its purposes, you know. MVVM doesn't mean no code-behind. It means removing code from the code-behind that shouldn't be there. Commented Sep 1, 2012 at 19:57
  • 1
    "70% in viewmodels and 30% code in code behind it's harded for you get into the application." - Sounds to me like an uninformed assumption. I have no problem reading code, no should any software developer. MVVM is about separating the presentation from the logic. That doesn't mean the logic goes away entirely. This all sounds very dogmatic. each situation is different, you do your best to create a maintainable application given your requirements. Commented Sep 1, 2012 at 20:41

1 Answer 1

Reset to default
3

Having a code behind free xaml.cs and moving to code to a new class does not mean its pure MVVM. The idea is you will have all the logic in ViewModel hence a code behind free View, helping in Unit Testing. View specific logic like colors and animation cannot be unittested hence doesnt matter where it resides, in an custom control or a inherited control or directly in xaml.cs. As long as you are testing most of the user interactions and view logic via UnitTesting, you should be happy that you have done a good job.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Yes I know. But I think you have a better MVVM support when you extend controls for your specific purposes. (For example the additional property for column binding). You can directly bind to this. If you have a big view and you have to write a lot of code-behind (for example because of some limitations like column binding) the code will be unreadable. (I'm not against code that has to be written in code behind. I just think it must be a better solution for this. Control extension or some other "patterns" whatever for handling this code better.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.