Lo que he hecho en el pasado es usar algo similar, Model-View-Presenter.
[NOTA: Este artículo solía estar disponible en la web.Para verlo ahora, deberá descargar el CHM, y luego ver las propiedades del archivo y hacer clic en Desbloquear. Luego puede abrir el CHM y encontrar el artículo. Gracias a un millón, Microsoft! suspiro]
El formulario es la vista, y tengo una interfaz IView para él. Todo el procesamiento ocurre en el presentador, que es solo una clase. El formulario crea un nuevo presentador y se pasa a sí mismo como IView del presentador. De esta forma, para las pruebas, puede pasar una IView falsa y luego enviarle comandos del presentador y detectar los resultados.
Si tuviera que utilizar un Modelo-Vista-Controlador de pleno derecho, supongo que lo haría de esta manera:
- La forma es la vista. Envía comandos al modelo, plantea eventos a los que el controlador puede suscribirse y se suscribe a eventos del modelo.
- El controlador es una clase que se suscribe a los eventos de la vista y envía comandos a la vista y al modelo.
- El modelo genera eventos a los que la vista se suscribe.
Esto cabría con the classic MVC diagram. La mayor desventaja es que con los eventos, puede ser difícil saber quién se está suscribiendo a qué. El patrón MVP usa métodos en lugar de eventos (al menos, la forma en que lo implementé). Cuando el formulario/vista genera un evento (por ejemplo, someButton.Click), el formulario simplemente llama a un método en el presentador para ejecutar la lógica. La vista y el modelo no tienen ninguna conexión directa; ambos deben pasar por el presentador.
Puede obtener una mejor respuesta si puede agregar más detalles a su pregunta. Por ejemplo, ¿en qué está el componente de tu modelo? Una base de datos o archivos persistentes o qué? Supongo que la parte de la vista será de formas simples, pero ¿quizás quieres decir eso? Los detalles hacen que una pregunta sea más fácil de abordar. –