CODEWITHSUNDEEP
c#wpfmvvmviewmodelmessagebox
Dee J. Doena
Dee J. Doena

Reputation: 1843

MVVM, ViewModel, Model & MessageBoxes

I understood the basic priinciple of not calling the MessageBox in the ViewModel code or the Model code but instead use a callback of some kind, be it an interface or a func declaration that is added to the ViewModel upon construction.

So far, so good.

But the examples given only go so far that you press a button in the View and then the ViewModel raises the MessageBox via callback to confirm and then continues.

But what if the Model is doing tons of stuff first before realizing the need for a user feedback? Do I give the model also the callback function to work?

Does it have to be designed differently?

Any advice is appreciated. :-)

Upvotes: 1

Views: 254

Answers (3)

Dee J. Doena
Dee J. Doena

Reputation: 1843

OK, I think I've figured it out.

In my model I've encapsulated every call to the file system in a self-written interface called IIOServices and all my UI calls in an interface called IUIServices.

The UIServices only use standard datatypes or self-defined enums and nothing from the System.Windows.Forms or System.Windows namespace.

Then the clients of the model are responsible for providing an implementation to access FileOpenDialogs and MessageBoxes and such in any way they please.

My sample code for this implementation (which is kept small for the learning experience) can be found here, if anyone's interested:

MVVM with MessageBoxes sample code

Upvotes: 0

pgenfer
pgenfer

Reputation: 622

In my opinion, it shouldn't be a big issue to raise the callback from your model, but I guess this depends on your architecture and your personal preferences.

So if you really don't want to have any callbacks connected to the view in your model, you could let your mvvm (or your presentation/application layer) handle the control flow instead of letting the model do it.

You could implement your model methods more fine grained and let the application layer coordinate the operations of your model. In that way, whenever a model operation is completed and a user input is required, the mvvm layer could raise the callback.

Example:

// method of your view model / application layer
public void InteractiveProcessing()
{
     // business logic is separated in smaller chunks
     model.DoFirstPartOfOperation();
     // check if model needs additional user input
     if(model.NeedsInput)
        // raise callback here, let user enter input etc...
     // continue processing with user input
     model.DoSecondPartOfOperation(userInput);
}

Of course this makes only sense if you could split up your business logic into smaller parts.

Upvotes: 1

Steve
Steve

Reputation: 11963

You expose a public event, and have the View (.xaml.cs) to listen to it on startup. The code is still going to run on the worker thread, but the backend logic will not hang during unit testing.

Upvotes: 0

Related Questions