No funciona así exactamente.
Lo primero es que tienes que darte cuenta de que MVC no es una ley de hierro, no hay unas normas o trucos que te permitan separar todo a la perfección, digamos que son una serie de recomendaciones que deberías aplicar según tu criterio para tener una aplicación separada en capas.
Lo segundo es que MVC no es algo que se aplica porque los que saben dicen que hay que hacerlo, hay que entender qué es el patrón MVC de forma que al conocer sus ventajas sabremos mejor cómo aplicarlo. Lo que se busca es dividir la aplicación en capas de forma que estén desacopladas, que se pueda cambiar alguna de las capas sin que afecte (o lo mínimo posible) al resto de capas.
Para mí donde mejor se ve es las aplicaciones web, en las aplicaciones de escritorio aparece un problema que comentaré luego.
En web es claro, cada proceso entra al servlet (controlador o precontrolador) que ejecuta los procesos usando los modelos, para finalmente transmitir la información al usuario a través de la vista (mediante modelos).
¿Qué sucede con las aplicaciones de escritorio? Que funcionan a través de eventos, por lo que quien ejerce de "precontrolador" son las vistas. Yo soy de web, así que lo que voy a decir ahora con pinzas porque puede ser erróneo.
A MÍ no me gusta que el Controlador reciba un objeto Vista, la Vista no es parte del negocio por lo que para el Controlador cuanto menos sepa de ella mejor. ¿Qué pasa si mañana mi aplicación pasa a ser web? Que ni sirve la Vista ni el Controlador porque depende de la Vista.
YO desde los listener de la Vista haría un new de un controlador (o usaría singleton u otro patrón del estilo que favorezca desacoplamiento) de forma que sus métodos recibiesen/devolviesen como parámetros objetos Modelo si es necesario. Así, la vista únicamente serviría para lanzar al Controlador o gestionar código relativo a la presentación, y el Controlador sería totalmente independiente de la Vista.