nhibernate - ¿Qué es exactamente "ignorancia de persistencia"?
orm poco (8)
En mi opinión, el "desconocimiento de la persistencia" es una propiedad de su modelo (modelo de dominio, modelo de negocio o lo que sea que le refiera). El modelo ignora la persistencia porque recupera instancias de las entidades que contiene mediante abstracciones (a veces denominadas repositorios). Estas abstracciones se pueden implementar mediante el uso de un ORM directamente, pero a medida que se declara, a veces esto puede agregar requisitos a los objetos que no pertenecen naturalmente a su modelo. Por lo tanto, no diría que un modelo que se adhiere a algunos requisitos de un ORM específico es 100% persistente e ignorante.
La ignorancia de persistencia generalmente se define como la capacidad de persistir y recuperar objetos .NET estándar (o POCO si realmente insiste en darles un nombre). Y una definición aparentemente bien aceptada de un objeto .NET estándar es:
"... clases ordinarias en las que te enfocas en el problema del negocio sin agregar cosas por razones relacionadas con la infraestructura ..."
Sin embargo, veo personas que describen NHibernate como un marco que permite la ignorancia de persistencia, y sin embargo es un marco que no puede funcionar en ningún objeto .NET estándar, solo objetos .NET estándar que se adhieren a requisitos de diseño particulares, por ejemplo ( source ):
- Todas las clases deben tener un constructor predeterminado
- Algunas características no funcionan a menos que las clases sean abiertas y todos los miembros sean virtuales
- La identidad del objeto no funciona correctamente a menos que abuse de Equals / GetHashCode
(Aparte: antes de que alguien se enoje, no me refiero a NHibernate aquí, es solo un ejemplo citado con frecuencia de un marco que supuestamente permite ignorancia de persistencia. Estoy seguro de que argumentos similares podrían aplicarse a otros ORM que afirman lo mismo .)
Ahora bien, aunque la clase en sí misma no tiene ningún atributo específico de marco de persistencia o clases base, etc., para mí no es realmente "persistencia ignorante" porque debe seguir un conjunto de pautas de diseño para facilitar el uso por el marco de persistencia elegido. Debe diseñar e implementar la clase teniendo en cuenta los requisitos del marco de persistencia; si lo ignoras, es posible que la clase no funcione.
Donde tengo problemas con la definición de "ignorancia de persistencia" / "POCO" es que no veo cómo, conceptualmente, esto es realmente diferente de agregar atributos como [Serializable] o [DataContract] o [XmlType] o cualquier otra anotación específica del marco de persistencia que facilite la persistencia y la recuperación de la entidad que utiliza ese marco.
Entonces, ¿qué es exactamente "ignorancia de persistencia"?
Claramente la definición de que es capaz de persistir en "clases ordinarias" es una falacia porque los NHibernate son solo ordinarios en la medida que no hacen referencia a clases específicas del framework, mientras que son extraordinarios en la medida en que requieren opciones de diseño inusuales tales como constructores por defecto y todo -virtual members y equivalentes / GetHashCode implementaciones en tipos mutables.
¿Es razonable decir que la "ignorancia de la persistencia" es verdadera cuando los objetos facilitan el uso de un marco de persistencia (ya sea en diseño y estructura o mediante el uso de anotaciones específicas del marco) pero no realizan ninguna lógica de persistencia ellos mismos?
Estoy de acuerdo con Mikeb: "la ignorancia de la persistencia" es una escala móvil, no una propiedad verdadera / falsa de un ORM dado.
Mi definición de verdadero 100% PI sería que usted podría persistir CUALQUIER clase POCO posible, sin importar cuán enrevesado y vinculado a otras clases, sin cambiar la clase de ninguna manera.
Agregar campos de ID, decorar con atributos, heredar de clases ORM, tener que diseñar sus clases para que se asocien bien con las tablas subyacentes en un RDB, todos reducen la "puntuación PI" por debajo del 100%.
Dicho esto, he elegido usar Fluither NHibernate Automapping porque parece tener el puntaje PI más alto de cualquiera de las opciones de ORM que he analizado.
Estoy de acuerdo con tu definición:
¿Es razonable decir que la "ignorancia de la persistencia" es verdadera cuando los objetos facilitan el uso de un marco de persistencia, pero no realizan ninguna lógica de persistencia ellos mismos?
El código (en oposición a los atributos) en sus clases no tiene características que sean intrínsecas a la persistencia. Los constructores por defecto pueden ser necesarios para la persistencia, pero no tienen código que realmente persista. La capa de persistencia se puede cambiar bastante sustancialmente, se pueden usar diferentes bases de datos y la lógica de negocios no se modificará.
No creo que tu comprensión (o definición) de "Ingestión de persistencia" sea incorrecta.
El verdadero problema es el de las abstracciones con fugas . Simplemente, la tecnología existente hace que sea muy difícil implementar PI verdadero.
Si bien puede haber ciertas limitaciones menores que requiere un marco de ignorancia de persistencia dado, persiste la ignorancia, sin embargo, permanece en su lugar.
Mientras que una clase en su modelo de dominio (persistió de forma transparente con NHibernate) debe tener un constructor sin argumentos para que pueda construirse "dinámicamente", no es necesario que tenga una determinada clase base dictada por el marco ni se requiere tener o anular ciertos métodos especificados por el marco.
Una clase ignorante persistente, es una clase que no está vinculada a un marco de persistencia.
Es decir, la clase no tiene absolutamente ningún conocimiento de que exista un marco de persistencia presente, no hereda de una clase definida por ese marco ni implementa una interfaz que se requiere para ese marco de persistencia para funcionar.
Yo diría que, como la mayoría de las cosas, es una escala móvil. Hay cosas que hacemos que quieren tener la propiedad de persistencia. En un extremo de la escala está esta cosa que tiene todas las agallas, dependencias y código que está hecho a la medida para persistir exactamente de esta manera en particular. En el otro extremo de la escala hay algo que simplemente sucede mágicamente, todo sin que hagamos mucho más que agregar un token o establecer una propiedad en algún lugar que haga que esa cosa ''simplemente persista''. Para llegar al lado mágico de la escala, hay marcos, pautas de diseño, convenciones, etc. que ayudan a que la magia suceda. Creo que podría argumentar que podría producirse una herramienta que tuviera menos requisitos y restricciones que NHibernate pero persiguiera el mismo objetivo; esa herramienta hipotética estaría más adelante en nuestra escala.
No sé si me gusta tanto el término "ignorancia de la persistencia"; en realidad se trata de un objeto que ignora la implementación, el almacén de respaldo, el caché, ese tipo de cosas; sin embargo, un objeto suele ser consciente de si es persistente o no. Pero eso es solo semántica.
puede implementar persisrtence ignorance utilizando una clase para el dominio o su aplicación y una clase POCO en la persistencia, cuando va a persistir el objeto de dominio mapearlo en su clase de persistencia y usar el objeto de persistencia para almacenar con nhibernate u otro marco
su clase de dominio debe ignorar cómo persiste la información, por lo que no debe incluir ninguna regla de un marco de persistencia como (constructor vacío, propiedades virtuales, etc.)
estas reglas de marco de persistencia pueden estar en su clase de persistencia.