La razón por la que generalmente están desacoplados es porque desea que su vista use un controlador para llegar a su modelo. Pero la arquitectura debería permitirle reemplazar una vista con otra sin tener que cambiar la lógica de negocios (es decir, el modelo de objeto o cómo se recuperan esos objetos).
Al no vincular su controlador directamente a la vista, más adelante sería mucho más fácil agregar otra funcionalidad como importar / exportar que puede usar el controlador / modelo directamente sin tener que depender de ninguna interfaz de usuario.
Otra ventaja de sacar la mayor cantidad de código posible de la interfaz de usuario es porque las interfaces de usuario son mucho más difíciles de probar en la unidad que la capa empresarial detrás de ellas. Al separar todo lo que pueda de la vista, puede escribir muchas más pruebas unitarias para asegurarse de que su controlador / modelo y la lógica de la aplicación sean correctos.
El controlador maneja la lógica de negocios que puede cambiar de vez en cuando, y la Vista puede permanecer sin cambios, según los requisitos.
Lo contrario de lo anterior también es cierto.
Los diseñadores y desarrolladores deben poder trabajar en el mismo proyecto de forma independiente.
Una buena publicación: http://mashable.com/2011/11/12/designer-collaboration-strategies/
Todo el sistema se vuelve más fácil de mantener. Resolver errores se vuelve más fácil con el enfoque desacoplado.
Los estándares web con tecnologías front-end están cambiando a un ritmo acelerado. Imagine una corporación que decide migrar todas las tecnologías de front-end a HTML5, Dart, etc. ¡Tener una vista y un controlador acoplados sería una pesadilla!
fuente
No tienes que separar los dos, por supuesto. Pero si la vista y el controlador son independientes, se puede utilizar cualquier interfaz de usuario. Por ejemplo, puede usar el controlador a través de la consola, los sockets, la web o la interfaz de escritorio. En otras palabras, puede aumentar la reutilización del código.
fuente