Implement MVVMC and dependency injection

Question

I just read this article about the MVVMC pattern. Now I have a question. Should the controller be entered in the ViewModel, or should the ViewModel be entered in the controller?

Answer 1

MVVMC is simply MVC where View is replaced with a pair of ViewModel.

• View interacts ONLY with ViewModel, taking advantage of the powerful data binding mechanisms in XAML-based technologies.
• ViewModel can notify the controller, but SHOULD NOT enter the controller.

I put together a simple sample based on the well-known Josh Smith sample on MSDN ... where I introduced the controller.

Answer 2

It depends on what you do. I am going to guess that most of the time the Controller does not need to be entered in any of them, but if necessary, it will most likely be needed in the ViewModel. Let me explain.

What are you doing with the controller? You have to do something .. If this “something” is exclusively related to “the way the data looks”, then it belongs to the view. If this is due to "what is shown to the user", then it belongs to the ViewModel.

I inject a controller into one of my ViewModels. My ViewModel represents the data that is then displayed in the view. I have a command that moves a data item from the current graph to a new graph. Since this changes “what is displayed in the chart window”, I ran a command in my ViewModel. The ViewModel removes the data item from its own set of elements, and then uses the controller to request the creation of a new view for this new data (it already had this functionality).

Looking at the article, I do not see the arrow between the controller and the view

Answer 3

ViewModel is a contract between View and Controller, and ideally you don't need to know about (depending on).

Therefore, I will definitely not enter the controller in the ViewModel.

I'm not sure I will do the opposite: the controller is usually responsible for creating new instances of the ViewModel. If you want to switch to a more loosely coupled implementation, you can go to enter the abstract factory in the controller to avoid directly creating new instances of the ViewModel classes.

Answer 4

I believe that the controller should be introduced as an abstraction of IController. To view the ViewModel, it is necessary that the IController can switch to another View / ViewModel.

For example, in ViewModel:

IController _controller; public MyViewModel(IController controller){ _controller = controller; } void NavigateHome(); { _controller.NavigateHome(); } 

IController abstraction is better than injecting the controller itself for the following reasons:

• Testability. You can enter mock IController and check ViewModel
• Disconnection. ViewModel does not need to know the controller.

I developed a lightweight framework for working MVVMC in WPF. It has a lot in common with MVC in Asp.NET Core.

Check this out if you are looking for a WPF solution.

Documentation blog post: http://michaelscodingspot.com/2017/02/15/wpf-page-navigation-like-mvc-part-2-mvvmc-framework/

GitHub: https://github.com/michaelscodingspot/WPF_MVVMC