¿Cuántos niveles deben tener mis modelos en una aplicación web basada en DB?

7

En mi experiencia, el "Modelo" en MVC a menudo no es realmente una sola capa. Regularmente tendría modelos "backend" y modelos "frontend", donde los backend tendrían propiedades que deseo ocultar del código de la interfaz de usuario, y los frontend tienen propiedades derivadas o compuestas que son más significativas en el contexto de la interfaz de usuario. .

Recientemente, comencé a introducir una tercera capa intermedia cuando la normalización de la base de datos creó tablas que ya no coincidían con los objetos del dominio conceptual. En esos proyectos tengo clases modelo que son equivalentes con la estructura de base de datos, estas se convierten en componentes de objetos que representan el modelo de dominio y, finalmente, se filtran y modifican para mostrar información al usuario.

¿Existen patrones o pautas sobre cómo, cuándo y por qué organizar el modelo de datos en las capas de aplicación?

    
pregunta Hanno Fietz 24.11.2011 - 21:42

2 respuestas

4

En node.js, generalmente uso solo tres capas.

Capa de datos:

Una capa simple que habla directamente con la fuente de datos. El único trabajo es extraer datos de la fuente de manera eficiente y escribirlos. El origen de datos puede ser cualquier cosa, un punto final TCP, un punto final HTTP, una base de datos, un sistema de archivos, etc.

Capa de dominio:

La capa de objeto de dominio. Esto es similar a tu "M" en MVC. Es una representación de objeto de un objeto de dominio. Tiene métodos para la construcción, manipulación, validación y otra lógica.

Tenga en cuenta que un solo objeto de dominio puede comunicarse con varios objetos diferentes de la capa de datos y que varias vistas pueden transformar un objeto de dominio.

Ver capa:

La vista toma un objeto de dominio y se transforma de una manera fácil de imprimir. Por ejemplo, en la capa de vista convertiría una marca de tiempo en una cadena legible para el ser humano o haría mi conversión de idioma i18n.

También hace cualquier otra lógica de vista. En general, tiene varios objetos de vista para un solo objeto de dominio.

Y, por supuesto, también convierte los datos del objeto de dominio al formato que desee, ya sea binario, xml, json, html, algún protocolo TCP arbitrario, texto sin formato, csv, etc.

Capa IO

Por lo general, también necesita alguna forma de capa de E / S que se comunique con las otras capas.

es decir, la capa IO

  • desempaqueta la entrada
  • llama al objeto de dominio correcto desde datos o desde una instancia de objeto de dominio
  • pasa la instancia de datos / dominio a través de la capa de vista
  • canaliza la información sin procesar devuelta desde la capa de vista (html / json / binary / ...) hacia abajo en la salida

Múltiples aplicaciones

Ahora una sola aplicación tiene estas tres capas. Si tuviera un sitio web dinámico, tendría estas tres capas en el servidor y estas tres capas en el cliente.

Si tuviera mi propio origen de datos único con el que hablar, entonces ese origen de datos remoto también usaría estas tres capas, tendría sus propios objetos de dominio, su propia capa de datos en sus propias fuentes de datos y su propia capa de vista que otros Los servicios hablan cuando me usan como fuente de datos.

Imagen bonita

Fuente de imagen

    
respondido por el Raynos 25.11.2011 - 01:21
3

Sus palabras clave son "Modelo de dominio enriquecido" y debe tener en cuenta el antipatrón de modelo de dominio anémico .

En mis aplicaciones (Java) tengo estas capas:

  1. Objetos comerciales (objeto de base de datos + comportamiento relacionado con los datos), asignados de forma transparente a DB a través de Hibernate, inyectados con dependencias de servicio usando Spring anotation @Configurable, ya que contienen dependencias, es posible tener datos + operación en un lugar - abrazar el diseño de OO (observe la diferencia al usar un modelo anémico, que tiene datos en una capa y operaciones en otra (este enfoque es de procedimiento y destruye el polimorfismo y la herencia)).
  2. Objetos de acceso a datos: encapsula la comunicación con la base de datos, esta capa se puede intercambiar fácilmente, si decido cambiar la implementación del acceso a la base de datos (por ejemplo, de JPA a JDBC o quizás a la base de datos de objetos)
  3. Capa de servicio: contiene acciones, que no operan sobre objetos comerciales (servicios hashich y criptográficos) y servicios, que operan sobre un conjunto de objetos comerciales, por lo tanto, una sola BO no podría tener esta responsabilidad.
  4. Fachada del servicio: la verdadera capa de servicio tal como se la conoce por el patrón . Encapsula la aplicación, proporciona API para llamadas desde el mundo exterior (solo aquellas operaciones, que son relevantes para las personas que llaman, sin problemas internos). La seguridad y el manejo de transacciones se realiza aquí. Además de la transformación de datos internos en objetos de transferencia de datos.
  5. Objetos de transferencia de datos: envoltorios simples, que solo contienen datos para ser transportados al mundo fuera de su aplicación. No puede usar su BO porque tienen métodos, que no pueden llamarse fuera sin contexto, y peor aún, contienen datos privados. Solo imagen, si es aconsejable enviar UserBO al mundo exterior, cuando contiene una contraseña con hash y el salt. Además, el DTO puede diferir de BO: pueden tener una granularidad diferente.
  6. Alguna capa de vista: uso JavaServerFaces. Pero con esta implementación, realmente no importa, sería lo mismo, si hubiera servicios web, REST o incluso una API binaria.

Y un enlace más para otro buen artículo de Alistair Cockburn - Arquitectura hexagonal / Puertos y adaptadores .

    
respondido por el malejpavouk 24.11.2011 - 22:41

Lea otras preguntas en las etiquetas