Enfoque de desarrollo: ¿interfaz de usuario entrante o salida de modelo de dominio?

Aunque nunca he entregado nada usando Smalltalk, mi breve tiempo jugando con él definitivamente ha dejado su huella. La única forma de describir la experiencia es MVC como debe ser. Esencialmente, todo el trabajo pesado para su aplicación se realiza en los objetos comerciales (o modelo de dominio si así lo desea). Los controles estándar están vinculados a los objetos comerciales de alguna manera. Por ejemplo, un cuadro de texto se asigna al campo de un objeto (el campo en sí es un objeto, por lo que es fácil de hacer). Un botón se asignaría a un método. Todo esto se hace con una API muy simple y natural. No tenemos que pensar en vincular objetos, etc. Simplemente funciona.

Sin embargo, en muchos lenguajes y API más nuevos, se ve obligado a pensar desde afuera hacia adentro. Primero con C ++ y MFC, y ahora con C # y WPF, Microsoft ha logrado que su mundo de desarrolladores se enganche en los constructores de GUI donde construye su aplicación implementando controladores de eventos . El desarrollo de Java Swing no es tan diferente, solo usted está escribiendo el código para instanciar los controles en el formulario usted mismo. Para algunos proyectos, puede que nunca haya un modelo de dominio, solo controladores de eventos. He estado dentro y alrededor de este modelo durante la mayor parte de mi carrera.

Cada forma te obliga a pensar de manera diferente. Con el enfoque Smalltalk, su dominio es inteligente mientras que su GUI es tonta. Con el enfoque predeterminado de VisualStudio, su GUI es inteligente mientras que su modelo de dominio (si existe) es bastante anémico.

Muchos desarrolladores con los que trabajo ven valor en el enfoque Smalltalk e intentan calzar ese enfoque en el entorno VisualStudio. WPF tiene algunas características de enlace dinámico que lo hacen posible; Pero hay limitaciones. Inevitablemente, parte del código que pertenece al modelo de dominio termina en las clases de GUI.

Entonces, ¿de qué manera diseñas / desarrollas tu código? ¿Por qué?

• GUI primero. La interacción del usuario es primordial.
• Dominio primero. Necesito asegurarme de que el sistema sea correcto antes de ponerle una IU.

Hay pros y contras para cualquier enfoque. El modelo de dominio encaja allí con catedrales de cristal y pastel en el cielo. GUI encaja allí con rápido y sucio (a veces realmente sucio).

Y para una ventaja adicional: ¿cómo se asegura de que el código sea mantenible?

Ninguno

A lo largo de los años que he estado desarrollando software, me encontré practicando la primera metodología porque siempre hay un "punto medio" a tener en cuenta. Coloque una interfaz entre el código de UI y el código comercial, y haga un acuerdo sobre lo que la UI necesita en este momento del dominio.

Permítanme hacer una figura para aclarar este concepto:

  +------+
  |  UI  | <- Think about how to make an effective user interface
  +------+
      |
      |
 +----------+
 | Contract | <--- This part over here is really REALLY important, man!
 +----------+
      |
      |
+--------------+
| Domain model | <- Think about what the user needs
+--------------+ 

De esa manera, puede trabajar de forma iterativa en la interfaz de usuario y el modelo de dominio por separado si el término medio deja en claro qué datos puede recibir la interfaz de usuario.

La razón por la que veo por qué algunos proyectos se vuelven imposibles de mantener es porque la interfaz entre los datos y la presentación ha sido apresurada o es inexistente (con un código de manejo de datos directo en la interfaz de usuario). He visto tantos proyectos donde el código de la base de datos residía dentro del código del formulario que he perdido la fe en la humanidad. Solo los pocos proyectos que he visto que tienen este punto medio rígido restaura esa fe perdida.

Realmente no importa desde qué extremo comience primero ... lo que importa es que tenga esa separación clara de preocupaciones en su lugar. Ese contrato en el medio define más o menos la aplicación o el sistema en cuestión. Piense en eso primero antes de ir de abajo hacia arriba o de arriba hacia abajo .

Dominio primero. Necesito asegurarme de que el sistema sea correcto antes de ponerle una IU.

Nada más se puede hacer funcionar, excepto en casos simples.

Comenzar desde la interfaz de usuario a menudo conduce a un software frágil y defectuoso que puede parecer divertido, pero a menudo tiene serios problemas en el modelo.

No es un hecho que la interfaz de usuario primero esté condenada al fracaso: si el modelo es lo suficientemente simple, entonces la interfaz de usuario se puede construir primero con la confianza de que el modelo funcionará bien al final.

En cualquier caso donde el modelo no se pueda imaginar fácilmente, primero debe construirse.

El peor de los casos es cuando algún programador cree que puede imaginar el modelo. Es posible que hayan omitido detalles importantes, casos especiales, excepciones o consideraciones de rendimiento. Dado que la GUI ya se ha creado, y se omitieron muchas consideraciones, el modelo es terrible.

Esto realmente depende de la aplicación en cuestión.

Si está creando una aplicación cliente / servidor cerrada, cualquiera de los dos enfoques sería suficiente; como va a manipular la parte trasera para adaptarse a las necesidades de las partes frontales inevitablemente.

Si está creando una aplicación abierta de cliente / servidor donde un posible servicio web quedará expuesto para que lo usen sus clientes, entonces es importante saber cómo ese servicio puede ser utilizado por un cliente para desarrollar un front end.

Muchas veces en los últimos tiempos con respecto a un impulso de pequeños ciclos iterativos en el desarrollo (Scrum, Kanban, etc.), el extremo frontal y el extremo posterior se realizan en paralelo. Se trata de proporcionar lo que necesita para esa iteración dada; sin tener en cuenta la construcción en caso de que necesitemos un enfoque . En un enfoque paralelo, ambos extremos permanecen mucho más cerca durante el desarrollo, lo que puede aliviar la necesidad de un cambio continuo cuando el extremo frontal y el extremo posterior se fusionan. Este es mi enfoque preferido cuando sea factible.

Mencionaste...

... WPF tiene algunas características de enlace dinámico que lo hacen posible; Pero hay limitaciones. Inevitablemente, un código que pertenece al modelo de dominio termina en las clases de GUI ...

¿No estás seguro de lo que quieres decir con algunos ? WPF y SL se destacan por su funcionalidad vinculante. Es interminable. Si se ve obligado a colocar código dentro de su Vista en una aplicación WPF basada en MVVM, entonces algo debe abordarse. Los comportamientos adjuntos son una forma de implementar el comportamiento sin vincular los eventos dentro de la vista, así como muchos otros enfoques para garantizar que su vista se mantenga limpia.

El front-end de una posición de interacción del usuario no debería tener nada que ver con la implementación del back-end. El único trabajo de back-end para un front-end es suministrar datos a través del procesamiento de datos u otros medios. Esto se relaciona con el tipo de aplicación que se está desarrollando.

Asegurarse de que el código fuente sea mantenible es realmente una pregunta completamente diferente en sí misma. A un alto nivel, pertenece a las mejores prácticas de codificación junto con los siguientes patrones, arquitecturas y tecnologías comprobadas.

Prefiero diseñar la interfaz de usuario básica primero (incluso si es solo en papel), con aportes del cliente. Es posible que el cliente no sepa realmente lo que quiere hasta que lo vea. No siempre puede confiar en lo que le dice el cliente. Podrías pasar semanas escribiendo un modelo de dominio robusto solo para descubrir que no se ajusta a lo que el cliente cree que quiere después de comenzar a ver los prototipos de interfaz de usuario.

Intentamos conducir nuestro software con pruebas automatizadas. Las pruebas de IU automatizadas requieren bastante tiempo. Las secuencias de comandos para verificar algunos valores en una consola son más fáciles.

Con eso en mente, tenemos mucho cuidado de mantener la lógica de negocios separada de la interfaz de usuario.

Recuerdo que incluso una vez que un desarrollador principal me gritó que la arquitectura de documento / vista se consideraba obsoleta cuando sugerí que debíamos dejar de vincular todo nuestro código comercial con la interfaz de usuario (y estábamos usando win32 en C ++ en ese momento, por lo que esta programación de arrastrar y soltar) ni siquiera era nuestro problema). Estaba simplemente atónito.

IMNSHO, simplemente no hay excusa para no tener al menos una capa de negocios versus UI. Si su producto hace algo levemente interesante, es absolutamente necesario que esta separación permita la reutilización del código.

Como desarrollador de C #, definitivamente no creo que estés encasillado para trabajar de afuera hacia adentro. Prefiero hacer el modelo de dominio primero, en realidad.

Para WPF, la única desventaja del modelo que describí, entonces, es que a veces necesitas mediar entre tu IU y tu modelo de dominio. Aún así, aunque eso a veces significa más trabajo, también significa un código más limpio.

Ciertamente, el dominio primero!

La belleza de Smalltalk es que puedes "manejar" un modelo de dominio de muchas maneras, incluyendo "imprimirlo" desde un espacio de trabajo o inspector. Solo cuando estaba seguro de que su dominio estaba funcionando como lo deseaba, se atrevió a concentrarse en crear la GUI perfecta.

Eso no quiere decir que Smalltalkers no funcionó en los dos al mismo tiempo, pero cuando su GUI no pudo implementar la lógica de negocios, generalmente arregló el modelo de dominio primero, en lugar de poner casos especiales en su GUI.