domain-driven-design - microsoft - domain entity

¿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 ignornacia de persistencia? 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 los archivos de clase o la base de datos, 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éjame 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();

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

Mueva ''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 método de este tipo usando los resultados y sabes qué persistencia es la ignorancia.

Si no está convencido, vea qué tan simple sería una prueba de unidad, porque no hay ninguna dependencia de las cosas relacionadas con la persistencia:

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 al crear una instancia de la entidad, almacenarla en la base de datos, recuperarla y compararla. 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.

Usted podría 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 las 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, el patrón de fábrica o el patrón del módulo no es nuevo también, pero es una parte bastante importante de DDD.

También comencé a utilizar NHibernate recientemente, por lo que no puedo 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 términos del dominio y, aunque he utilizado procedimientos almacenados, ADO.NET en el pasado, solo cuando me mudé a NHibernate estaba satisfecho con mi mecanismo de persistencia.

Domain Driven Design (DDD) pone énfasis 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.

Fluidez NHibernate reduce el impacto que los cambios en su modelo de dominio tienen en los archivos de mapeo subyacentes. También tiene auto mapeo . 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 cuanto a probar tus asignaciones, estarías escribiendo pruebas (o DEBERÍAS hacerlo) sin importar el método que utilices 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.

Nuevamente para este Fluido NHibernate es invaluable. Tiene una prueba de especificación de persistencia que es realmente simple de usar en la mayoría de los casos.