0

In Form-based application (WPF/MVVM/SQLServer), consider the form that handles the classical actions that you can perform on any entity.

  • Create
  • Read
  • Update
  • Delete

The problem, in general terms, is simple to tell.
which class of the viewmodel competes the call of any of the above actions?
What is clear:
* the ultimate actions compete to the model, that handles the business logic
What is unclear, i'll explain with this example. Say that I have a model class that represent a Person. This class will have basic CRUD methods, say static NewInstance (C), static Load (R), Save (U), static static Delete(object key) (D).

Now the problem.
When I bring up a Person instance, I most likely will do it through a PersonViewModel, that will have expose a SaveCommand that in turn will call the save method of the underlying model.

Should this viewmodel have also the create command? This would be quite unnatural, because either:

  • the PersonViewModel is capable of undloading the underlying model and loading another one, thing that may be less than easy, depending on how much 'wiring' is going on between model and viewmodel

  • the command acts just as a relay for an external class that actually unloads the viewmodel and loads the new one. This is a bit contrived because in this case we have a code that unloads the object that contains it, and this requires additional assessments of correctness.

So all of these seems to be code smells that indicate that Create doesn't belong to PersonViewModel.
Which class does it belongs to then?
I'm thinking of factory method in a 'viewmodel' variation. But solutions like that seems all to be over-engineered so I'm asking if there is a well-established pattern (possibly there are multiple ones) for this issue.

1 Answer 1

1

Should this viewmodel have also the create command?

Yes.

the PersonViewModel is capable of unloading the underlying model and loading another one, thing that may be less than easy, depending on how much 'wiring' is going on between model and viewmodel

That's what the ViewModel is for. It holds the 'wiring' for converting the model into values that the View can display. It knows if the user is creating a new item, or editing or copying an existing one. The model doesn't know this, and the view doesn't care.

1
  • From the MVVM point of view this seems ok. What I'm trying to do is to stick with the MVVM paradigm without loosing the single-use ViewModel. That's because implementing a reusable viewmodel is a much more complex task than instantiating a single-use viewmodel. It's not only expensive, is'ts risky too because an unwiring error may lead to nasty errors like 'zombie models' to be revived. All the additional coding and testing and attention required is just boilerplate, that is it doesn't add any additional value to the application. So I think that both mvvm and singleuse vm should coexist.
    – AgostinoX
    Mar 12, 2020 at 10:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.