El patrón del Controlador resuelve la siguiente pregunta "¿Quién debe atender las llamadas de las clases de Interfaz de Usuario?"

Es decir, supongamos que en nuestra aplicación tenemos un nivel responsable de presentar la información al usuario y atender sus peticiones. Este nivel estará formado por clases de "interfaz de usuario". Así, cuando un usuario quiera ejecutar el caso de uso "comprar", completará un formulario con los datos del pedido y pulsará el botón "Comprar".

La clase de interfaz de usuario (supongamos ComprarIU) comprobará la corrección de los datos, que todos los campos requeridos han sido completados, etc. Y, ahora ¿a quién llama?

Una opción sería que ComprarIU instanciaria un objeto Compra, completara sus datos, instanciara un objeto Cliente, los asociara, comprobara el crédito, calculara los impuestos... Pero no parece la responsabilidad adecuada para una clase de interfaz de usuario. Procediendo de esta forma, la clase ComprarIU asumiría prácticamente toda la responsabilidad.

El patrón Controlador propone que las clases de IU realicen sus peticiones a una clase inventada (inexistente en el modelo de negocio) denominada "Controlador".

La responsabilidad de la clase Controlador es servir de interfaz entre las clases de IU y las de dominio. Así ComprarIU se limitará a comprobar los datos recibidos (como es su responsabilidad) y llamará al Controlador para que prosiga la operación. Será responsabilidad del Controlador comprobar los permisos del usuario e instanciar los objetos de negocio necesarios para realizar la operación solicitada.

En aplicaciones muy pequeñas, un sólo controlador puede gestionar todas las peticiones. Pero en una aplicación mediana o simplemente pequeña (no muy pequeña), esta clase puede llegar a contener cientos de métodos. Lo normal suele ser establecer una clase controlador por cada caso de uso, facilitando así la modularidad de la aplicación.