Quels sont les “gros” avantages d’avoir Poco avec ORM?

POCO est une question de couplage et de testabilité lâches.

Ainsi, lorsque vous exécutez POCO, vous pouvez tester votre modèle de domaine (si vous exécutez DDD par exemple) séparément. Vous n’avez pas à vous soucier de la façon dont cela persiste. Vous n’avez pas besoin de stub des contextes / sessions pour tester votre domaine.

Un autre avantage est qu’il y a moins d’abstractions qui fuient. Parce que les problèmes de persistance ne sont pas poussés vers la couche de domaine. Donc, vous appliquez le principe SRP.

Le troisième avantage que je peux voir est que faire POCO votre modèle de domaine est plus évolutif et flexible. Vous pouvez append de nouvelles fonctionnalités plus facilement que si elle était couplée à la persistance.

J’utilise POCO lorsque je fais du DDD par exemple, mais pour un type d’application, vous n’avez pas besoin de faire du DDD (si vous utilisez de petites applications basées sur des données), donc les problèmes ne sont pas les mêmes.

J’espère que cela t’aides

Aucun. Point. Tous les avantages que les gens aiment utiliser sont des avantages qui ne sont pas importants à grande échelle. Je préfère une classe de base forte pour les objects d’entité contenant beaucoup de code intégré (comme le lancement d’événements de modification de propriété lorsque des propriétés changent) plutôt que l’écriture de tout cela moi-même. Notez que j’ai écrit un ORM pour .NET (à ce moment disponible dans le commerce) avant que “LINQ” ou “ObjectSpaces” n’existent même. Cela fait 15 ans que je me sers de mappeurs O / R, et je n’ai jamais trouvé de cas où POCO valait vraiment la peine.

Cela dit, les atsortingbuts PEUVENT être mauvais pour d’autres raisons. Je préfère plutôt l’approche NHibernate Fluent ces jours-ci: après avoir lancé mon propre mappeur (maintenant abandonné) avec des atsortingbuts, puis déplacé vers des fichiers XML.

Le thème “POCO ne m’apporte rien” provient principalement du fait que les entités NE SONT PAS DES OBJETS NORMAUX. Ils comportent de nombreuses fonctionnalités supplémentaires, ainsi que des limitations (telles que la vitesse des requêtes, etc.), dont l’utilisateur doit être informé de toute façon. Les ORM, malgré LINQ, ne sont de toute façon pas remplaçables – non si vous commencez à utiliser leurs fonctionnalités les plus intéressantes. Donc, à la fin, vous obtenez POCO et vous êtes toujours nul avec une classe de base et une sémantique différente à gauche et à droite.

Je trouve que la plupart des partisans de POCO (comme dans: “doit avoir”, pas “serait gentil”) n’ont normalement pas pensé leurs arguments à la vraie fin. Vous obtenez toutes sortes de pensées assez merdiques, à peu près au niveau de “les procédures stockées sont plus rapides que le SQL dynamic”, ce qui n’est tout simplement pas vrai. Des choses comme:

• “Je veux les avoir dans les cas où ils n’ont pas besoin de sauvegarder la firebase database” (utilisez un pool d’objects séparé, ne jamais valider),
• “Je peux vouloir avoir ma propre fonctionnalité dans une classe de base (l’ORM doit allos entité abstraite classée sans fonctionnalité, placez donc votre classe de base OWN sous celle de l’ORM)
• “Je souhaiterais peut-être remplacer l’ORM par un autre” (afin de ne jamais utiliser de fonctionnalités supérieures, espérons que l’API ORM est compatible et vous devrez peut-être encore réécrire de grandes parties).

En général, les utilisateurs de POCO oublient également l’énorme quantité de travail nécessaire pour le rendre DROIT – avec des choses telles que les mises à jour d’objects transactionnels, etc., il existe une tonne de code dans la classe de base. Certaines des interfaces .NET sont horribles à implémenter au niveau POCO, bien que beaucoup plus faciles si vous pouvez vous connecter à l’ORM.

Prenez le poste de Thomas Jaskula ici:

POCO est une question de couplage et de testabilité lâches.

Cela suppose que vous puissiez tester la liaison de données sans l’avoir? La testabilité est un simulacre de framework, et il en existe VRAIMENT puissants qui peuvent même “redirect” les appels de méthodes.

Ainsi, lorsque vous exécutez POCO, vous pouvez tester votre modèle de domaine (si vous effectuez DDD par exemple) de manière isolée. Vous n’avez pas à vous soucier de la façon dont cela persiste. Vous n’avez pas besoin de stub des contextes / sessions pour tester votre domaine.

En fait pas vrai. La persistance doit faire partie de tout test de modèle de domaine, car le modèle de domaine doit être conservé. Vous pouvez toujours tester des scénarios non persistants en ne validant tout simplement pas les modifications, mais bon nombre des tests impliquent la persistance et l’échec de celle-ci (par exemple, les factures contenant des données non valides / manquantes ne peuvent pas être écrites).

Un autre avantage est qu’il y a moins d’abstractions qui fuient. Parce que les problèmes de persistance ne sont pas poussés vers la couche de domaine. Donc, vous appliquez le principe SRP.

En fait non. Un modèle de domaine approprié n’aura jamais de méthodes de persistance dans les entités. C’est un ORM de merde pour commencer (user.Save ()). OTOH, la classe de base se chargera de choses telles que la validation (IDataErrorInfo), gérera les événements de mise à jour des propriétés sur les fichiers persistants et vous fera en général gagner beaucoup de temps.

Comme je l’ai déjà dit, certaines des fonctionnalités que vous DEVRIEZ avoir sont très difficiles à implémenter avec des variables en tant que magasin de données – comme la possibilité de mettre une entité en mode de mise à jour, d’effectuer des modifications, puis de les restaurer. Inutile – Indiquez à Microsoft qui l’utilise, s’il est disponible dans ses grids de données (vous pouvez modifier certaines propriétés, puis appuyez sur échap pour annuler les modifications).

Le troisième avantage que je peux voir est que faire POCO votre modèle de domaine est plus évolutif et flexible. Vous pouvez append de nouvelles fonctionnalités plus facilement que si elle était couplée à la persistance.

Non-argument. Vous ne pouvez pas jouer sur l’ajout de champs à une classe de péristet sans gérer la persistance, et vous pouvez append des fonctionnalités (méthodes) non persistantes à une classe non-poco de la même manière qu’à une classe poco.

En général, ma classe de base non POCO a:

• Gérez les mises à jour des propriétés et IDataErrorInfo – sans que l’utilisateur écrive une ligne de code pour les champs et les éléments que l’ORM pourrait gérer.
• Gérer les informations d’état d’object (Nouveau, Mise à jour, etc.). Ce sont des informations insortingnsèques IMHO qui sont également assez souvent poussées vers le bas à l’interface utilisateur. Notez qu’il ne s’agit pas d’une méthode “save”, mais simplement d’une propriété EntityStatus.

Et elle contenait un certain nombre de méthodes que l’entité pouvait utiliser pour étendre le comportement SANS implémentation d’une interface (publique), de sorte que les méthodes étaient réellement privées de l’entité. Il disposait également de propriétés internes supplémentaires, telles que l’access au “gestionnaire d’objects” responsable de l’entité, ce qui était également le sharepoint demander d’autres entités (soumettre des requêtes), qui étaient parfois nécessaires.

Le soutien de POCO dans un ORM consiste à séparer les préoccupations, en respectant le principe de responsabilité unique . Avec la prise en charge de POCO, un ORM peut communiquer directement avec un modèle de domaine sans avoir à «brouiller» le domaine avec un code spécifique à l’access aux données. Cela garantit que le modèle de domaine est conçu pour résoudre uniquement les problèmes liés au domaine et non les problèmes d’access aux données.

En outre, la prise en charge de POCO peut faciliter le test du comportement des objects de manière isolée, sans avoir besoin d’une firebase database, d’informations de mappage ou même de références aux assemblys ORM. La possibilité d’avoir des objects “autonomes” peut considérablement faciliter le développement, car les objects sont simples à instancier et à prédire.

De plus, les objects POCO n’étant pas liés à une source de données, vous pouvez les traiter de la même manière, qu’ils aient été chargés à partir de votre firebase database primaire, d’une firebase database alternative, d’un fichier plat ou de tout autre processus. Bien que cela puisse ne pas sembler immédiatement bénéfique, traiter vos objects de la même manière, quelle que soit la source, peut rendre le comportement facile à prévoir et à utiliser.

J’ai choisi NHibernate pour mon ORM le plus récent en raison de la prise en charge des objects POCO, une fonction très bien gérée. Cela convient à l’approche de conception par domaine suivie par le projet et a permis une grande séparation entre la firebase database et le domaine.

Pouvoir changer d’outils ORM n’est pas un argument réel pour le support de POCO. Bien que vos classes puissent ne pas avoir de dépendance directe sur l’ORM, leur comportement et leur forme seront limités par l’outil ORM et la firebase database vers laquelle elle est mappée. Changer votre ORM est aussi important que de changer de fournisseur de firebase database. Il y aura toujours des fonctionnalités dans un ORM qui ne seront pas disponibles dans un autre et vos classes de domaine refléteront la disponibilité ou l’absence de fonctionnalités.

Dans NHibernate, vous devez marquer tous public membres de classe public ou protected comme virtual pour permettre la prise en charge du chargement différé. Cette ressortingction, bien que ne modifiant pas de manière significative ma couche de domaine, a eu un impact sur sa conception.