WPF properties in the View Model interface?

Question

Using vanilla WPF (no MVVM framework such as Prism).

Let me say that I absolutely protect coding against abstractions / interfaces compared to implementations when possible.

In WPF, when you do bindings in a view, you really don't code the bindings to the viewmodel interface. You are really attached to the implementation of viewmodel / datacontext. I think you can even claim that you are attached to an empty canvas, since the view does not really know what it will be attached to at runtime.

So, a view model interface that includes all the properties that the view will be bound to useless abstraction? If the interfaces of the model model should be more compact, they contain only the methods necessary for changing the state (or control commands, etc.).

I hope this question makes sense. :)

Answer 1

IMHO, ViewModel is a model for presentation. 90% of the time they are likely to be from 1 to 1 ... the useful part will return the logic to something more verifiable than XAML. Together they make up the user interface, but the user interface behavior is separate from the user interface representation.

Personally, I do not use ViewModel interfaces. Between the Command pattern and the loose binding used by WPF and Silverlight, I don't feel like abstraction will be useful.

I could use ViewModel interfaces on a system where the behavior and view state were very different based on some business criteria. For instance. if your view had editing the license field on the driver, and the required fields varied from state to state, you could make a case for one complex view associated with the IStateDriversLicenseViewModel interface. A dependency introduced based on the state you are working on may be correct, and it may expose properties such as IsOrganDonorSectionVisible so that the view displays the correct changes. However, in this case, I suspect that a view composed of user controls will result in fewer problems and less maintenance complexity.

Answer 2

Abstraction [i.e. programming the interface] is useful if and only if loose communication is desired [ie. agnostic interdependence between consumer and producer].

Depending on your interpretation of the Model View ViewModel [MVVM], tight coupling is allowed.

In practice, the typical scenario I saw is a tight connection between View and ViewModel and between View and Model (s). Typically, since views are designed to fulfill a specific business requirement, ViewModels are tailored to the View approach to facilitate the View's business role.

As Ben Von Handorf suggests , the part of our application that actually adapts the base model (s) in the ViewModel should be separate from our presentation [at least the declarative part of the presentation]. Thus, adaptation is usually captured by the implementation of the View command. Thus, although the declarative aspect of View does not know the underlying model (s) and is loosely coupled, the business implementation or View command introduces a tight connection between View and Model. Again, this is awesome, because the purpose of the Single Submission is to use this data in a certain way as part of its activities.

I am also a fan of abstraction, in particular, programming the interface, dependency injection [DI] and control inversion [IoC]. However, when a tight connection makes sense, as in MVVM, abstraction is an over-complication.

IMO, the simplicity introduced through tight coupling, makes MVVM so attractive to its cousins ​​in the Model View Controller [MVC] space.

Answer 3

I think it’s generally unwise to define an interface when you only ever create one class that implements it. This describes every view model class I have ever created. And the view cannot use interfaces in any way.

I sometimes use interfaces in model classes, but only if I need to define interactions between those classes that are not true in the model.