Acabo de leer el artículo this sobre el patrón MVVMC. Ahora tengo una pregunta. ¿Debería inyectarse Controller a ViewModel, o ViewModel debe ser inyectado en Controller?Implementación de MVVMC e Inyección de Dependencia
El ViewModel es un contrato entre la Vista y el Controlador, y lo ideal es que no necesite conocer (dependa de) tampoco.
Así que definitivamente no estaría inyectando un Controlador en un ViewModel.
No estoy seguro de que haga lo contrario: el controlador es normalmente responsable de crear nuevas instancias de ViewModel. Si desea una implementación más flexible, puede optar por inyectar una fábrica abstracta en el Controlador, para evitar crear directamente nuevas instancias de sus clases de ViewModel.
Pero cuando inyecte Controller en ViewModel, seguirá siendo un patrón MVVM, de hecho. El controlador tiene toda la lógica, que se proporciona (en una clase de controlador) para ver el modelo. Hay muchos servicios inyectados en el controlador. ¿Está mal? –
Depende de lo que esté haciendo. Voy a adivinar que la mayoría de las veces el Controlador no necesitaría ser inyectado en ninguna de las dos, pero si es necesario, es más probable que sea necesario en ViewModel. Dejame explicar.
¿Qué estás haciendo con el controlador? Debe estar haciendo algo ... Si ese "algo" está relacionado únicamente con "a qué se parecen los datos", entonces pertenece a la Vista. Si está relacionado con "lo que se muestra al usuario", entonces pertenece al ViewModel.
Estoy inyectando un controlador en uno de mis ViewModels. Mi ViewModel representa datos que luego se grafican en la Vista. Tengo un comando que mueve un elemento de datos del gráfico actual a un nuevo gráfico. Como esto cambia "lo que se muestra en la ventana del gráfico", implementé el comando en mi ViewModel. ViewModel elimina el elemento de datos de su propia colección de elementos y luego usa el controlador para solicitar que se cree una nueva vista para esos datos nuevos (ya tenía esta funcionalidad).
Mirando el artículo, no veo flechas entre el controlador y la vista 
El MVVMC es simplemente una MVC donde la vista se sustituye por un par modelo de vista.
He reunido una muestra simple basada en la muestra bien conocida de Josh Smith en MSDN ... donde he presentado un controlador.
Creo que el controlador debe ser inyectado como una abstracción IController. ViewModel necesita IController para poder navegar a una vista/modelo de vista diferente.
Por ejemplo, en ViewModel:
IController _controller;
public MyViewModel(IController controller){
_controller = controller;
}
void NavigateHome();
{
_controller.NavigateHome();
}
La abstracción IController es mejor que inyectar el propio controlador por estas razones:
Desarrollé un marco liviano para hacer MVVMC en WPF. Tiene mucha semejanza con MVC en Asp.NET Core.
Échale un vistazo si estás buscando una solución WPF.
Blog post con la documentación: http://michaelscodingspot.com/2017/02/15/wpf-page-navigation-like-mvc-part-2-mvvmc-framework/
Tal vez estoy pasado de moda, pero lo que realmente necesita este patrón? No estaba muy impresionado con la justificación hecha por el autor en el artículo vinculado. Parecía estar programando para el "qué pasaría si" en lugar del "ahora mismo" que viola el principio de YAGNI. Algunas de las afirmaciones fueron un poco extremas también. Cada vez que agregue otra capa de abstracción (y esta es solo la capa de UI de la que estamos hablando), la complejidad de la solución aumenta. Solo espero el día en que tengamos MVVMCMVPVMVC ... para dibujar un control. –
¿Qué hay del desorden en un código de ViewModel? –
Supongo que depende de cómo se defina "desastre". ¿Tiene un problema específico que está resolviendo con la adición de un controlador? –