¿Cuáles son los beneficios de Persistence Ignorance?

Question

Soy un novato en el DDD + TDD World. Pero he estado programando durante casi 9 años.

¿Puede alguien explicarme los beneficios de la persistencia de la ignornacia? La aplicación típica nHibernate simplemente empuja la dependencia entre la clase y la base de datos a los archivos de mapeo.

Si cambio de archivos o base de datos de clase, tengo que cambiar los archivos de mapeo. Entonces, ¿no es solo presionar la dependencia al agregar una capa de abstracción más? En mi opinión hasta ahora, no creo que sea algo revolucionario. Pero no estoy seguro de si me falta algo.

Finalmente ¿Cómo puedo probar los archivos de mapeo? Hay posibilidades de que aparezcan errores de los archivos de mapeo, ¿cómo puedo probarlos?

Answer 1

Déjenme explicar esto con un ejemplo. Supongamos que está implementando una aplicación utilizando un enfoque SQL clásico. Abre conjuntos de registros, cambia datos y los confirma.

pseudo código:

trx = connection.CreateTransaction(); 
query = connection.CreateQuery("Select * from Employee where id = empid"); 
resultset = query.Run(); 
resultset.SetValue("Address_Street", "Bahnhofstrasse"); 
resultset.SetValue("Address_City", "Zürich"); 
trx.Commit(); 

Con NHibernate se vería algo como esto:

emp = session.Get<Employee>(empid); 

// persistence ignorant 'logic' 
emp.Address.Street = "Bahnhofstrasse"; 
emp.Address.City = "Zürich"; 

session.Commit(); 

Persistencia La ignorancia significa que la lógica de negocio en sí mismo no sabe nada de la persistencia. O, en otras palabras, la persistencia está separada de la lógica. Esto lo hace mucho más reutilizable.

Mover 'lógica' a un método reutilizable:

void MoveToZuerichBahnhofstrasse(Employee emp) 
{ 
    // doesn't have anything to do with persistence 
    emp.Address.Street = "Bahnhofstrasse"; 
    emp.Address.City = "Zürich"; 
} 

intenta escribir un procedimiento de este tipo utilizando conjuntos de resultados y usted sabe lo persistencia es la ignorancia.

Si su no están convencidos, a ver cómo simple sería una prueba de unidad, porque no hay ninguna dependencia a la persistencia cosas relacionadas:

Employee emp = new Employee(); 
MovingService.MoveToZuerichBahnhofstreasse(emp); 
Assert.AreEqual("Bahnhofstrasse", emp.Address.Street); 
Assert.AreEqual("Zürich", emp.Address.City); 

---

DDD es algo diferente. Allí construye su modelo de dominio primero (modelo de clase) y crea el diseño de la base de datos de acuerdo con él. Con NH esto es muy simple, porque, gracias a la ignorancia de persistencia, puede escribir y probar el modelo y la lógica de la unidad antes de tener un modelo de base de datos (definitivo).

---

Pruebas: Estamos probando asignaciones mediante la creación de una instancia de la entidad, almacenándolo a la base de datos, recuperarlo y compararlo. Esto se hace automáticamente con mucha reflexión. Pero no necesitas ir tan lejos. la mayoría de los errores típicos aparecen cuando se trata de almacenar una entidad.

Puede hacer lo mismo con las consultas. Las consultas complejas merecen una prueba. Es más interesante si la consulta se compila en absoluto. Ni siquiera necesitas datos para esto.

Para pruebas de integración de bases de datos, estamos usando Sqlite. Esto es bastante rápido. NH produce la base de datos en memoria sobre la marcha utilizando SchemaExport (antes de cada prueba).

Answer 2

PI no se trata de usar NHibernate. PI significa ignorar cómo se almacenarán los datos al desarrollar el modelo de dominio. Y sí, está impulsando la dependencia al agregar una capa de abstracción más. DDD no es revolucionario: se parece más a una idea, a un enfoque de cómo codificar utilizando patrones ya familiares (la mayoría de ellos lo son). Es decir. - patrón de fábrica o patrón de módulo no es nuevo también, pero es una parte muy importante de DDD.

empecé a usar NHibernate hace poco también, así que - no puede proporcionar muchos detalles al respecto. Pero tengo un consejo que podría ser útil para ti: prueba Fluent NHibernate si aún no lo has hecho.

Answer 3

Siempre he pensado en el término del dominio y, aunque he utilizado procedimientos almacenados, ADO.NET en el pasado, fue solo cuando finalmente me mudé a NHibernate que estaba satisfecho con mi mecanismo de persistencia.

Domain Driven Design (DDD) pone el énfasis en ángulo recto en el modelo de dominio. Esto significa que el objetivo principal es crear un modelo conceptual que forme un lenguaje común tanto para los usuarios como para los programadores. Los usuarios casi NUNCA están interesados ​​en cómo está persistiendo su información. NHibernate le ayuda a lograr este modo de pensar haciendo que la persistencia sea una preocupación secundaria a la captura de las reglas comerciales y la comprensión de lo que el usuario realmente desea del sistema.

Fluent NHibernate reduce el impacto que los cambios en el modelo de dominio de tener en los archivos de asignación subyacentes. También tiene auto mapping. Si bien nunca puede ignorar por completo la persistencia de su sistema, NHibernate con Fluent NHibernate le permite enfocarse en el modelo de dominio. Si no se está enfocando en usar un modelo de Dominio enriquecido, NHibernate tiene poco beneficio.

En lo que respecta a las pruebas de sus asignaciones, estaría escribiendo pruebas (o debería ser), no importa qué método se utiliza para implementar la persistencia. Esto no es trabajo adicional que aparece solo porque estás usando NHibernate. Solo piense en probar sus asignaciones como prueba de que su persistencia funciona correctamente.

de nuevo para este Fluent NHibernate es inestimable. Tiene un Persistence Specification Testing que es realmente simple de usar en la mayoría de los casos.