Encapsular los casos de uso de un software

Question

Yo suelo escribir casos de uso de todo el software que desarrollo. Para cada caso de uso por lo general escribo un controlador que dirige el flujo (implementa un caso de uso).

Recientemente he comenzado a desarrollar aplicaciones web con Asp.net MVC. Una de las mejores prácticas de Asp.net MVC es mantener muy menos lógica en los controladores. No soy capaz de averiguar cómo voy a cambiar mi diseño para reflejar esto.

Básicamente quiero una forma de encapsular mis casos de uso.

Answer 1

Crear un componente de negocio para encapsular los casos de uso. Por ejemplo, si usted tiene un sistema de gestión de las licencias que tendría casos de uso como solicitar una licencia, aprobar una solicitud de licencia, rechaza una solicitud de licencia, etc. Para ello se puede crear un componente de negocio (clase) llamado Dejar Manager con métodos (funciones / operaciones) como "Aplicar", "Aceptar", el "rechazo", etc. Estos métodos encapsular los casos de uso. Estos métodos tomarían sus entidades empresariales y clases de almacenamiento de datos como entrada y ejecutar el caso de uso.

class LeaveManager{
     int Apply(from, to);

     bool Approve(leaveApplicationId, approverId);

     bool Reject(leaveApplicationId, approverId);
}

A continuación, puede utilizar este componente de negocio en sus controladores para ejecutar el caso de uso mediante el suministro de los parámetros necesarios.

Answer 2

Creo que tener un modelo de controlador de grasa y flaco es generalmente una buena práctica en cualquier idioma y no específicamente .NET MVC. Pedido de este bonito que pasa a través de un escenario de ejemplo mostrando las ventajas de un modo de grasa en Ruby on Rails (pero las ideas se aplican a cualquier idioma).

Para que representa los casos de uso en su código, creo que un lugar mucho mejor para ellos es en los casos de prueba en lugar del controlador.

Answer 3

Empuje tanto la lógica de negocio a sus modelos y clases de ayuda como sea posible, y utilizar controladores principalmente para el manejo de llamadas URL y crear instancias de los modelos relevantes, recuperar datos de ellos, y empujando a los datos de los puntos de vista. Vistas y controladores deben tener el menor número de decisiones que tomar como sea posible.