¿Cómo vinculo un objeto de dominio en la memoria a sus registros de la base de datos sin saturar el dominio con preocupaciones de la base de datos?

7

Su modelo de dominio contiene un conjunto de objetos. Estoy aquí presentando un proyecto paralelo, pero tengo un proyecto de trabajo mucho más complicado que cae de rodillas porque no hice una buena separación de la base de datos y el dominio.

En este caso, el objeto se llama CyclingRecord.

Siguiendo Onion Architecture , los objetos de dominio no saben nada de su persistencia. Sin embargo, cada uno de esos objetos corresponde a una entrada en un almacén de datos (potencialmente una base de datos, potencialmente un archivo). La ID de la fila no forma parte del objeto del dominio y, por lo tanto, no tiene ningún negocio almacenado en el objeto del dominio.

data CyclingRecord = CyclingRecord { date :: Day,
                                     distance :: Float,
                                     time :: Integer,
                                     description :: Maybe String }

En un lenguaje que impone una fuerte inmutabilidad (como Haskell y Clojure), identidad y valor son sinónimos. Además, no hay ninguna razón por la que no pueda grabar más de un viaje en un día. Por lo tanto, todo el registro describe completamente un viaje.

Entonces, si edito un registro en el Dominio, cuando vuelvo a pasar los objetos editados a la Infraestructura de la Base de Datos, ¿cómo hago para notificar a la base de datos que necesita actualizar un registro en particular en lugar de eliminar un registro existente? / p>

(la misma idea debería ser extensible para que una aplicación pueda manipular muchos registros a la vez y luego enviarlos a la base de datos. Operación sin conexión o sincronización o simplemente evitar la actividad excesiva del disco)

A menos que la respuesta correcta sea realmente hacer algo como un identificador único para cada viaje. Tal vez un UUID. Tal vez agregue un "contador de días" al registro. Hágala parte intrínsecamente de un paseo en bicicleta y luego haga que la base de datos dependa de ella en lugar de una ID de fila separada.

    
pregunta Savanni D'Gerinel 01.05.2012 - 19:54

4 respuestas

2

La respuesta correcta es hacer algo como un identificador único para cada viaje. Las entidades necesitan una identidad que, en este caso, realmente está separada de la combinación de fecha, distancia, tiempo y descripción. Está diciendo que estas cosas pueden cambiar, mientras que la identidad no puede.

Entonces, dales algo inmutable: un UUID, si quieres.

    
respondido por el Matthew Flynn 01.05.2012 - 20:57
1

Parece que tu marca de tiempo debe ser única, ¿por qué no usarla como tu clave principal? En su lógica de persistencia, puede realizar una eliminación previa (eliminar siempre todos los registros con la misma marca de tiempo, luego insertar) o verificar si ya existe un registro e insertar o actualizar según corresponda.

Alternativamente, puedes usar algún tipo de decorador o objeto complementario para mantener los metadatos de persistencia. Su lógica de persistencia debería tener alguna forma de hacer coincidir los metadatos con el registro cíclico y crearlo o actualizarlo cuando persista el registro.

Si determina que realmente necesita una identificación única, ¿por qué no asigna un "número de viaje"? Eso suena como algo razonable para grabar. Puede ser un número secuencial, o puede generarlo desde la marca de tiempo (por ejemplo, "201205011045" para un viaje que realizó a las 10:45 del 1 de mayo de 2012).

    
respondido por el TMN 01.05.2012 - 20:58
0

Si su base de datos tiene un identificador único, no hay razón para no incluirlo como parte del modelo de dominio. Incluso si no tiene ningún otro significado (por ejemplo, Número de empleado, nombre de usuario, dirección de correo electrónico, VIN del automóvil, etc.).

De lo contrario, tiene que confiar en alguna otra combinación de campos o en cada objeto para tener un número único asignado en el mundo real.

Esta es la clave para actualizar o eliminar datos (teóricamente, puede seleccionar un registro por cualquier otro número de campos exactamente como lo haría un usuario en un formulario de búsqueda). Los objetos inmutables no tienen este problema con la actualización.

    
respondido por el JeffO 01.05.2012 - 21:24
0
  • La independencia de persistencia (o ignorancia, no recuerdo el término correcto) es difícil y, a veces, imposible de lograr con ciertas tecnologías. P.ej. (LINQ to SQL en una pila de tecnología .NET es un no-no, ya que se basa completamente en la estructura de la base de datos). Si ese es el caso, entonces tienes que aceptarlo y vivir con él.

  • No hay nada de malo en agregar un identificador único a su modelo de dominio. Si te hace más feliz, entonces puedes crear una anotación para denotar que el atributo anotado no es parte de un modelo de dominio.

  • En cuanto a las comprobaciones para ver si el objeto ha cambiado, puede agregar una columna de marca de tiempo. Esto es relativamente barato. Tendría que implementar el seguimiento del estado del objeto o elegir un marco de persistencia que ya pueda hacerlo por usted.

  • La alternativa al estado de seguimiento es verificar todas las propiedades para ver si han cambiado, pero esto no es suficiente por sí solo.

  • Mi pregunta es si puede justificar una necesidad tan fuerte de independencia de persistencia completa. Buscar la perfección es bueno, pero a veces hay que dibujar una línea.

  • Finalmente, la mayoría de sus problemas pueden resolverse parcialmente, si no es que no, con los marcos existentes de persistencia de datos.

respondido por el CodeART 01.05.2012 - 21:29

Lea otras preguntas en las etiquetas