I was recently grabbing an auto generated TreeViewItem from a nested TreeView node in WPF, and I was using ItemContainerGenerator to get it in code behind. Then I thought to myself I'm certainly violating MVVM right now.

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.
If this question can be reworded to fit the rules in the help center, please edit the question.

4

Just a quick note, it's perfectly acceptable to use code-behind in MVVM providing it is related to the View only. With MVVM, you don't want any application or business logic in the code-behind because it violates the separation of concerns that each layer has. But it's fine to write something in the code-behind that is specific to the View only. Some things I recall doing recently is setting default focus and adjusting the view for the initial load.
–
RachelNov 15 '12 at 21:16

3 Answers
3

The ViewModel is aware of the View. The ViewModel should never know or care if or what is sitting on top of it. It simply is. Sometimes, the ViewModel might need to generate events that should be handled on the View. When I was working with MVVM, we used the Mediator pattern to handle those cases.

The Model is aware of any other component. The layers build up. The View is aware of the ViewModel and the Model (because it databinds against it), the ViewModel is aware of the Model, and the Model is aware of nothing.

There is logic in the View that does anything other than things specific to the implementation of that View. All generic View state and logic should exist in the ViewModel, but sometimes implementation details are needed in the View. These should be sparing and never interested in anything other than View implementation-specific items.

There is one common pattern that runs throughout: separation of concerns. If any layer of MVVM is interested in anything other than its concern, there is a problem.

I always wondered about #1 - while it makes sense for the business logic, I don't apply it to a lot of UI-related code. As an example: I am displaying some data in a Datagrid. When the User clicks on a row, this sends an event to the BL, which executes some transformations. These transformations are applied to the DataGrid, but the Grid cannot refresh Row-Colors through binding (or I have never found it). So I call a Method which simply gets the view, calls refresh on the datagrid and done. The interaction between BL and UI is very low - it is easy to mock this one refresh-Method
–
Christian SauerDec 20 '13 at 7:23

For Example

Having a declarative-only View makes it easier for non-programmer UI designers to change the UI. If you have code behind, then they will have to manage that code. The ViewModel doesn't care who is above it, doesn't care what View is consuming it. It is possible to have multiple views, for example a read-only and an edit View.

The ViewModel (VM) shouldn't be talking to the backing data store, that should be the job of the model. So having your VM work with the database directly would be a violation, that's the job of your Model.

My Opinion

Personally I make MVVM my own. There are the design principles I follow to the best of my ability but if the pattern becomes burdensome then I may violate it here or there and note it. It is supposed to make things easier on large projects, not harder.

However, with a lot of the MVVM frameworks there are for you to use now-a-days, it would be best to just pick one that fits and stick with it. These are designed to reduce the burden of the pattern and it should be an absolute best effort to not violate the pattern.

I think I violate the pattern because I use a WCF reference as my Model and talk to it from my ViewModel. I believe I'm supposed to actually create the Model manually and have that talk to WCF directly. I find this to be too much work.

If your projet has at least one of the above, then you are violating MVVM.

Also, MVVM is a particular case of the PM (Presenter Model) where developers don't need to implement the link between the View and the ViewModel. Since the PM is a more general scenario you cannot comply with MVVM without complying with PM basics.