Qu'est-ce que "persistance ignorance"?
L'ignorance de persistance est généralement définie comme la capacité de persister et de récupérer des objets. net standard (ou poco si vous insistez vraiment pour leur donner un nom). Et une définition apparemment bien acceptée d'un objet. net standard est:
"...classes ordinaires où vous vous concentrez sur le problème commercial à portée de main sans ajouter des choses pour des raisons liées à l'infrastructure..."
Cependant, je vois des gens décrire NHibernate comme un cadre qui permet la persistance l'ignorance, et pourtant c'est un framework qui ne peut pas fonctionner sur Tout objet. net standard, seuls les objets. net standard qui adhèrent à des exigences de conception particulières, par exemple (source):
- , Toutes les classes doit avoir un constructeur par défaut
- certaines fonctionnalités ne fonctionnent pas à moins que les classes ne soient descellées et que tous les membres soient virtuels
- L'identité de L'objet ne fonctionne pas correctement sauf si vous abusez de Equals / GetHashCode
(à part: Avant que quelqu'un ne se fâche, Je ne veux pas prendre NHibernate ici, c'est juste un exemple fréquemment cité d'un cadre qui permet soi-disant l'ignorance de la persistance. Je suis sûr que des arguments similaires pourraient être appliqués à d'autres Orm qui prétendent la même chose.)
Maintenant, bien que la classe en elle-même n'ait pas d'attributs spécifiques à la persistance ou de classes de base, etc., pour moi, ce n'est pas vraiment "persistance ignorante" car il doit suivre un ensemble de directives de conception pour faciliter l'utilisation de par le cadre de persistance choisi. Vous devez concevoir et implémenter la classe avec les exigences du framework de persistance à l'esprit; si vous l'ignorez, la classe peut ne pas fonctionner avec elle.
Où j'ai des problèmes avec la définition de "persistence ignorance"/" POCO", c'est que je ne vois pas en quoi, conceptuellement, cela est vraiment différent de l'ajout d'attributs tels que [Serializable] ou [DataContract] ou {[2] } ou toute autre annotation spécifique au framework de persistance qui faciliter la persistance et la récupération de l'entité utilisant ce cadre.
Alors, qu'est-ce que "persistance ignorance"?
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 que dans la mesure où ils ne font pas référence à des classes spécifiques au framework, alors qu'ils sont extraordinaires car ils nécessitent des choix de conception inhabituels tels que les constructeurs par défaut et les membres implémentations sur les types mutables.
Est-il donc raisonnable de dire que "l'ignorance de persistance" est vraie lorsque les objets facilitent l'utilisation d'un framework de persistance (soit dans la conception et la structure, soit par l'utilisation d'annotations spécifiques au framework) mais n'effectuent aucune logique de persistance eux-mêmes?
8 réponses
Je dirais que, comme la plupart des choses, c'est 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, cette chose a tous les tripes, les dépendances et le code qui est construit sur mesure pour persister juste cette chose à sa manière particulière. À l'autre extrémité de l'échelle, il y a quelque chose qui se passe comme par magie, tout cela sans que nous fassions beaucoup plus que d'ajouter un jeton ou de définir une propriété quelque part qui fait que cette chose est juste persist'. Afin d'arriver au côté magique de l'échelle, il y a des cadres, des directives de conception, des conventions, etc. qui aident la magie à se produire. Je pense que vous pourriez soutenir qu'un outil pourrait être produit qui avait moins d'exigences et de restrictions que NHibernate mais poursuivait le même objectif; cet outil hypothétique serait plus loin sur notre échelle.
Je ne sais pas que j'aime tellement le terme 'persistence ignorance'; c'est vraiment à propos d'un objet ignorant de l'implémentation, le magasin de sauvegarde, le cache, ce genre de chose - un objet est généralement conscient de sa persistance ou non. Mais c'est juste de la sémantique.
Je ne crois pas que votre compréhension (ou définition) de "persistance Ingorance" est fausse.
Le problème réel est celui des abstractions qui fuient . Tout simplement, la technologie existante rend Très difficile à mettre en œuvre le vrai PI.
Je suis d'accord avec Mikeb - "l'ignorance de persistance" est une échelle mobile, pas une propriété vraie/fausse d'un ORM donné.
Ma définition de vrai 100% PI serait que vous pourriez persister n'importe quelle classe poco possible, peu importe comment alambiquée et liée à d'autres classes, sans changer autrement la classe de quelque façon que ce soit.
Ajouter des champs ID, décorer avec des attributs, hériter des classes ORM, avoir à concevoir vos classes afin qu'elles soient bien mappées aux tables sous-jacentes dans un RDB-all reduce le "score PI" inférieur à 100%.
Cela dit, j'ai choisi D'utiliser L'Automapping NHibernate fluide car il semble avoir le score PI le plus élevé de l'une des options ORM que j'ai examinées.
Je suis d'accord avec votre définition:
Est-il donc raisonnable de dire que "persistance ignorance" est vrai quand les objets facilitent l'utilisation d'un cadre de persistance, mais ne le font pas effectuer toute logique de persistance eux-mêmes?
Le code (par opposition à atributes) dans vos classes n'a pas de fonctionnalités intrinsèques à la persistance. Les constructeurs par défaut peuvent être nécessaires pour la persistance, mais n'ont pas de code qui fait réellement la persistance. La couche de persistance il pourrait être modifié de manière assez substantielle, différentes bases de données pourraient être utilisées et la logique métier resterait inchangée.
Une classe ignorante persistante, est une classe qui n'est pas liée à un cadre de persistance.
C'est-à-dire que la classe n'a absolument aucune connaissance qu'il existe un framework de persistance, elle n'hérite pas d'une classe définie par ce framework et n'implémente pas non plus une interface requise pour que ce framework de persistance fonctionne.
Bien qu'il puisse y avoir certaines contraintes mineures que tout cadre de persistance-ignorance donné exige, la persistance-ignorance reste néanmoins en place.
Alors qu'une classe dans votre modèle de domaine (persistante de manière transparente avec NHibernate) doit avoir un constructeur no-arguments pour pouvoir être construite "dynamiquement", il n'est pas nécessaire d'avoir une certaine classe de base dictée par le framework ni d'avoir ou de remplacer certaines méthodes spécifiées par le framework.
À mon avis, "persistence ignorance" est une propriété de votre modèle (modèle de domaine, modèle d'affaires ou tout ce que vous pourriez appeler). Le modèle est ignorant de la persistance car il récupère les instances des entités qu'il contient à travers des abstractions (parfois appelées référentiels). Ces abstractions peuvent être implémentées en utilisant directement un ORM, mais comme vous le dites vous-même, cela peut parfois ajouter des exigences aux objets qui n'appartiennent pas naturellement à 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 ignorante.
Vous pouvez implémenter persisrtence ignorance en utilisant une classe pour le domaine ou votre application et une classe POCO dans la persistance, lorsque vous allez persister l'objet de domaine le mapper dans votre classe de persistance et utiliser l'objet de persistance pour stocker avec nhibernate o autre framework
Votre classe de domaine doit ignorer comment les informations sont persistantes, vous ne devez donc pas inclure de règles d'un framework de persistance comme (constructeur vide, propriétés virtuelles, etc.)
Ces les règles du cadre de persistance peuvent être dans votre classe de persistance.