oo pregunta - lógica del controlador de mezcla y lógica comercial

Question

No estoy seguro de si estoy usando términos "estándar", pero esta es una pregunta OO básica que estoy tratando de resolver.

Estoy codificando un formulario de Windows. No quiero lógica en el controlador de eventos de formulario, así que solo realizo una llamada a un objeto personalizado desde allí.

En el objeto personalizado, hay dos conjuntos de lógica.

1. La lógica del "controlador", que decide qué debe hacerse y cuándo.
2. La lógica de negocio real que hace lo que se necesita hacer (por ejemplo, un control que realiza una operación matemática y devuelve resultados, etc.).

Mi pregunta es, ¿la arquitectura OO permite tener ambas cosas en un solo objeto? ¿O se recomienda dividirlos en un objeto "controlador" y un objeto "lógica de negocios"? ¿Hay un patrón de diseño al que debería referirme para esto?

Por el momento, comencé la ruta de combinarlos en un solo objeto. Este objeto tiene un método de "inicio" que contiene la lógica del controlador. Este método llama a otros métodos del objeto según sea necesario y, en última instancia, devuelve los resultados a la persona que llama del objeto.

Answer 1

En general, probablemente debería tener estos en dos objetos diferentes, pero hay un calificador en eso. Puede tener sentido, si su proyecto es lo suficientemente pequeño y su modelo de objetos no es lo suficientemente complejo, para tener la funcionalidad compuesta en un objeto; Sin embargo, si su funcionalidad es lo suficientemente compleja, es casi seguro que será mejor para usted segregar el controlador y los objetos comerciales. Por lo menos, diseñe el sistema con la vista puesta en separar el controlador y los objetos comerciales en un momento posterior, si no los separa por completo ahora.

Answer 2

No, no pongo lógica comercial en los controladores. Agrego una capa de servicio intermedio que se inyecta en los controladores. Deje que el servicio haga el trabajo. Los controladores son para las solicitudes de enrutamiento y las respuestas de clasificación.

Poner la lógica en una capa de servicio limpia está "orientada al servicio", incluso si no está utilizando servicios web o WSDL. Tiene el beneficio adicional de seguir funcionando si decide cambiar las tecnologías de control/vista.

Answer 3

Lo que estás haciendo es una forma de arquitectura de "controlador de grasa". En la actualidad, el desarrollo de software tiende a controladores delgados.

OO design is all about desacoplamiento. Si internaliza solo una cosa acerca de la programación OO, que así sea.

Revisa "Domain-Driven Design Quickly." Este e-book gratuito es una introducción condensada a los conceptos cubiertos en el importante libro de Eric Evans "Domain-Driven Design".

Obtener información sobre estos conceptos debería ayudarlo a comprender cómo separar la lógica empresarial del controlador o capa de servicio.

Answer 4

La respuesta a su pregunta de diseño es la siguiente: ¿cómo diseñaría su aplicación si también tuviera que proporcionarle un cliente web?

Tanto la interfaz de usuario de Windows Forms como la interfaz de usuario web estarían llamando a las mismas clases y métodos. La única diferencia, entonces, sería cómo cada uno llena la interfaz de usuario y se comunica con las otras capas.