Personally, I'm more a fan of including a controller in there. I kind of mix MVVM and MVC together. My class defenitions then look like this:
public class SomeController : Controller
public class SomeModel : Model
public class SomeView : View, ISomeView
In the constructor of the view, I'll create the controller, which exposes a model property. That model will then be set on the datacontext. When creating the controller, I'll pass the view to the constructor so that the controller has a reference to the view as well (under the form of an interface). This way, you can unit test the controller and assert your model states while mocking the view... and, you won't have any ugly code-behind in your *.xaml.cs file, aside from some eventhandler methods like a button_Click. And in those methods, you'll only have 1 line anyway, which will be a controller call like Controller.XButtonClicked() or whatever. For LOB applications, this works great. This also opens up a lot of possibilities for standard control behaviour you may wish to have like automatic busy indicators etc.
modified on Thursday, April 28, 2011 8:10 AM
