Nous devons implémenter un service .NET WCF qui fera partie d'une solution SOA, ce qui signifie que ses entités passeront et seront modifiées à la fois par les services Java & .NET, ainsi que par les clients Desktop. (bien qu'ils seront probablement .NET, mais cela ne devrait pas avoir d'importance).ORM sans état pour SOA
Afin de réaliser cette flexibilité, tous les objets doivent être sans état car nous ne pouvons pas faire circuler le fichier .dll qui contient les implémentations d'entité & modifier la logique de suivi (toutes les définitions d'objet seront récupérées par wsdl).
Les entités qui seront communiquées seront dans un graphique, par exemple, quelques racines principales, puis chacune d'elles a une collection, qui a ses propres collections, etc ... chaque partie de la collection peut être modifiée/supprimé/inséré. Je sais que nous pourrions utiliser les DTO, mais c'est un overhead (surtout avec des graphes d'objets, des pointeurs circulaires, etc ...) et je voudrais l'éviter pour l'instant. Mais si rien d'autre ne se vérifie, il se peut que nous devions aller de l'avant ...
J'ai utilisé Entity Framework & LLBLGenPro avant, mais j'aimerais connaître votre opinion. Donc, enfin:
Quel serait votre choix d'un ORM dans un environnement SOA?
Merci
Je ne pense pas que la question fondamentale "quel ORM" change juste parce que l'environnement est SOA. ORMs décent peuvent gérer SOA très bien. –
Eh bien, c'est le cas - Les entités LLBL exigent que leur DLL soit désérialisée, les entités de structure Entity héritent toutes de system.data.entity, de sorte qu'elles ne fonctionnent pas correctement sur Java par exemple. Il y a des solutions de contournement bien sûr, mais c'est pourquoi je pose la question - peut-être qu'il y a quelque chose qui n'a pas besoin d'une solution de contournement – veljkoz