Reputation: 6424
First, take a look at this question and answer. In the supplied code in the answer, there is no call to PrintDialog.Showdialog()
, so this example is using the dialog object to quickly print something.
However, the PrintDialog
itself is a view, and the visual to print is a view, so I would think all of this should go in the view. The data for the view is in the ViewModel, the view to print should be built by the view, then fired off to the printer (just like the view fires off visuals to the screen). Is this a right way to think of MVVM in this manner?
I was thinking of displaying the PrintDialog to the user from the view, then passing the dialog into the viewmodel for printing, but it just seems to break the idea behind MVVM.
Upvotes: 0
Views: 1932
Reputation: 2319
First, moderators typically close open ended, discussion like questions like this. You should narrow your question so it can be definitively answered.
Second, any time you pass something that is clearly "view" oriented into your viewmodel, you are violating separation of concerns. Also, any activity in the viewmodel that could block a unit test from completing execution should be an immediate red flag that you are breaking MVVM. In this case, a print dialog displaying and waiting for input or being in a modal state would cause a unit test to time out or hang.
The solution would be to pass a service class in that performs the work of printing the grid, showing a dialog, and whatever work is required to get the job done. In MVVM, most of us use dependency injection (DI) to do this (I use MEF). You would create another service with the same interface for your tests to use that wouldn't block execution. The service, in this case, is a view layer service, and should have no dependency back to the viewmodel. The only thing the viewmodel knows is that it has a service interface to call into, and the only thing the service knows about the viewmodel is the interface it implements for this interaction (unless you can just set all the needed data on the service through it's own interface).
For further reference when you think you might be taking the wrong approach to OOAD, see SOLID (object-oriented design). It isn't definitive, but it is excellent guidance.
Upvotes: 2