Qu'est-ce que « l'ignorance de la persistance »?

Question

ignorance de persistance est généralement définie comme la capacité à persister et récupérer des objets standards .NET (ou Poços si vous insistez vraiment leur donner un nom). Et un définition apparemment bien acceptée d'un standard objet .NET est :

  

« ... les classes ordinaires où vous vous concentrez sur le problème d'affaires à portée de main sans y ajouter des choses pour des raisons liées à l'infrastructure ... »

Cependant, je vois des gens qui décrivent NHibernate comme un cadre qui permet à l'ignorance de la persistance, et pourtant il est un cadre qui ne peut pas travailler sur any objet .NET standard, seuls les objets standards .NET qui adhèrent à particulier les exigences de conception, par exemple ( la source ):

• Toutes les classes doivent avoir un constructeur par défaut
• Certaines fonctionnalités ne fonctionnent pas, sauf si les classes sont descellés et tous les membres sont virtuels
• identité objet ne fonctionne pas correctement à moins que vous maltraitez Equals / GetHashCode

  

(A part. Avant que quiconque se fâche, je ne veux pas prendre le NHibernate ici, il est juste un exemple souvent cité d'un cadre qui permet soi-disant ignorance de la persistance, je suis sûr que des arguments similaires pourraient être appliquées à d'autres ORM qui prétendent le même.)

Maintenant, bien que la classe en elle-même ne possède pas d'attributs spécifiques à la persistance cadres ou classes de base, etc., pour moi, ce n'est pas vraiment « persistance ignorants », car il doit suivre un ensemble de lignes directrices de conception pour faciliter utiliser le framework de persistance choisi. Vous devez concevoir et mettre en œuvre la classe avec les exigences du cadre de la persistance à l'esprit; si vous l'ignorez la classe ne peut pas travailler avec elle.

Là où je vais avoir du mal à la définition de « l'ignorance de la persistance » / « poco » est que je ne vois pas comment, sur le plan conceptuel, ce qui est vraiment différent des attributs ajoutant tels que [Serializable] ou [DataContract] ou [XmlType] ou tout autre annotations spécifiques à la persistance-cadre que facilitent la persistance et la récupération de l'entité en utilisant ce cadre.

Alors, quel est exactement "l'ignorance de la persistance"?

Il est clair que la définition de celui-ci comme étant capable de persister « classes ordinaires » est une erreur, car les NHibernate ne sont ordinaires dans la mesure où pas référence à des classes spécifiques-cadres, alors qu'ils sont extraordinaires dans la mesure où ils ont besoin des choix de conception inhabituels tels que par défaut les constructeurs et les membres tous virtuels et equals / implémentations GetHashCode sur les types mutables.

Est-il donc raisonnable de dire que « l'ignorance de la persistance » est vrai lorsque les objets facilitent l'utilisation d'un framework de persistance (soit dans la conception et la structure ou par l'utilisation d'annotations spécifiques au cadre), mais ne réalisent pas la logique de persistance eux-mêmes?

Answer 1

Je prétendre que, comme la plupart des choses, son une échelle mobile. Il y a des choses que nous faisons qui veulent avoir la propriété de la persistance. À une extrémité de l'échelle est cette chose ayant tous les tripes, les dépendances et le code qui est construit sur mesure à persister juste une chose dans sa façon particulière. À l'autre extrémité de l'échelle est quelque chose qui ne se passe comme par magie, tout cela sans nous faire beaucoup plus que l'ajout d'un jeton ou définir une propriété quelque part qui fait cette chose à « persister juste ». Afin d'obtenir le côté magique de l'échelle, il y a des cadres, des lignes directrices de conception, conventions, etc qui aident la magie qui se passe. Je pense que vous pourriez faire valoir qu'un outil pourrait être produit qui avait moins d'exigences et restrictions que NHibernate, mais a poursuivi le même objectif; cet outil hypothétique serait plus le long de notre échelle.

Je ne sais pas que j'aime le terme « persistance ignorance » tant; son vraiment un objet ignorant la mise en œuvre, la mémoire de sauvegarde, le cache, ce genre de chose - un objet est généralement conscient de si oui ou non il est persistant, cependant. Mais c'est la sémantique.

Answer 2

Je ne crois pas que votre compréhension (ou définition) de « persistance Ingorance » est erroné.

Le véritable problème est celui de abstractions qui fuient . Tout simplement, la technologie existante rend très difficile à mettre en œuvre véritable PI.

Answer 3

Je suis d'accord avec mikeb -. « Ignorance persistence » est une échelle mobile, pas une propriété vrai / faux d'un ORM donné

Ma définition de la vraie PI 100% serait que vous pourriez persister toute classe possible poco, peu importe la façon dont alambiquée et lié à d'autres classes, sans changer sinon la classe de quelque façon.

Ajout de champs d'identification, la décoration avec des attributs, héritant des classes ORM, d'avoir à concevoir vos classes afin qu'ils carte bien aux tables sous-jacentes dans un RDB -. Tout réduire le « score de PI » en dessous de 100%

Cela dit, je l'ai choisi d'utiliser Fluent NHibernate AutoMapping car il semble avoir le score le plus élevé PI de l'une des options ORM j'ai regardé.

Answer 4

Je suis d'accord avec votre définition:

  

Est-il donc raisonnable de dire que   « L'ignorance de la persistance » est vrai lorsque   objets facilitent l'utilisation d'un   framework de persistance, mais ne pas   exécuter une logique de persistance   eux-mêmes?

Le code (par opposition à atributs) dans vos classes n'a pas de caractéristiques intrinsèques à la persistance. constructeurs par défaut pourraient être nécessaires à la persistance, mais ils ont pas de code qui ne fait persistance. La couche de persistance pourrait être modifiée de façon substantielle, les bases de données différentes peuvent être utilisées et la logique métier ne changerait pas.

Answer 5

Une classe ignorante persistante, est une classe qui est pas liée à un cadre de persistancy.

C'est, la classe n'a absolument aucune connaissance qu'il ya un présent cadre persistancy, il ne hérite d'une classe qui est définie par ce cadre ni mettre en œuvre une interface qui est nécessaire pour que le cadre de persistence pour travailler.

Answer 6

Bien qu'il puisse y avoir certaines contraintes mineures que tout cadre persistance ignorance donnée, il faut, la persistance ignorance reste néanmoins en place.

Alors qu'une classe dans votre modèle de domaine (persisté de manière transparente avec NHibernate) doit avoir un pour qu'il puisse être construit constructeur sans arguments « dynamique », il n'est pas nécessaire d'avoir une certaine classe de base dictée par le cadre, ni est-il doivent avoir ou remplacer certaines méthodes spécifiées par l'ossature.

Answer 7

A mon avis, « l'ignorance de la persistance » est une propriété de votre modèle (modèle de domaine, le modèle d'affaires ou tout ce que vous pourriez parler comme). Le modèle est la persistance ignorant, car il extrait les instances des entités qu'il contient par des abstractions (parfois appelés référentiels). Ces abstractions peut être implemened en utilisant un ORM directement, mais comme vous vous déclarez cela peut parfois ajouter des exigences aux objets qui ne font pas partie naturellement dans votre modèle. Par conséquent, je ne dirais pas qu'un modèle qui adhère à certaines exigences d'un ORM spécifique est 100% persistance ignorant.

Answer 8

vous pouvez mettre en œuvre persisrtence ignorance en utilisant une classe pour le domaine ou votre application et une classe POCO dans la persistance, lorsque vous allez persister dans le domaine carte de l'objet dans votre classe de persistance et utiliser l'objet de persistance pour stocker avec o NHibernate autre cadre

votre classe de domaine doit ignorer comment persistée l'information, vous devez donc pas inclure des règles d'un cadre de persistance comme (constructeur vide, propriétés virtuelles, etc.)

ces règles-cadres de persistance peuvent être dans votre classe de persistance.