Je suis actuellement étudiant dans une application .NET n-tier qui utilise Nhibernate + WCF + WPF. Une des choses qui se fait assez terriblement est la sérialisation de graphe d'objet, en fait ce n'est pas fait du tout, actuellement les associations sont ignorées et nous utilisons des DTO partout. Pour autant que je sache, une méthode consiste à prédéfinir quels objets et collections doivent être chargés et sérialisés pour traverser le fil, afin de présenter certaines associations au client, mais cela semble limité, inflexible et incohérent (pouvez-vous dire que je n'aime pas cette idée). Une option qui m'est venue à l'esprit était de simplement remplacer le NHProxies que la collecte de charge paresseuse sur le niveau client avec un "disconnectedProxy" qui récupérerait les trucs associés sur le fil. Cela signifierait que nous devions élargir un peu notre signature de service Web et faire du piratage sur nos proxys générés, mais cela semblait être une bonne expérience de génération de code T4/autre. Autant que je sache, cela semble être une pierre d'achoppement commune, mais après avoir lu beaucoup de choses, je n'ai pas été en mesure de trouver de bonnes solutions généralement acceptées. Je cherche un peu de direction autant qu'une solution particulière, mais s'il y a un moyen facile de faire en sorte que le client «sente» connecté, faites-le moi savoir.graphe d'objet traversant du client n-tier
Répondre
Cela a été un moment pour moi, mais les proxies d'injection/déconnecté peuvent ne pas être aussi mauvais que cela puisse paraître. Puisque vous êtes un étudiant, je vais supposer que vous avez un peu de temps et que vous voulez passer un peu de temps.
Si vous souhaitez injecter votre propre logique de sérialisation/désérialisation personnalisée, vous pouvez utiliser IDataContractSurrogate qui peut être appliqué en utilisant DataContractSerializerOperationBehavior. J'ai seulement fait quelques choses de base avec ceci mais cela peut valoir la peine d'être examiné. En ajoutant une logique amusante (lire: potentiellement hackish) à cette couche, vous pourriez être en mesure de le rendre plus connecté.
Here est un message MSDN sur quelqu'un qui est venu à la même réalisation, DynamicProxy utilisé par NHibernate ne permet pas de sérialiser directement les objets NHibernate effectuant un chargement paresseux.
Vous posez une très bonne question qui malheureusement n'a pas une réponse très propre. Même si vous pouviez charger le chargement paresseux sur WCF (ce que nous pouvions faire), vous auriez encore des problèmes avec l'intercepteur proxy. Croyez-moi sur celui-ci, vous voulez des objets POCO sur le niveau client!
Ce que vous devez vraiment considérer ... ce qui a été conçu comme l'approche standard de l'industrie à ce problème de la recherche que je l'ai vu, est appelée persistance par rapport à l'utilisation ou ignorance persistance. En d'autres termes, votre modèle d'objet et vos mappages représentent votre domaine de persistance, mais ils ne correspondent pas à vos scénarios d'utilisation idéaux. Vous ne voulez pas apporter toute la base de données au client juste pour afficher quelques propriétés non?
Cela semble être un problème si simple, mais la solution est très simple ou très complexe. D'une part, vous pouvez concevoir vos entités autour de vos scénarios d'utilisation, mais vous vous retrouvez avec la prolifération de votre domaine objet, ce qui le rend difficile à maintenir. D'autre part, vous voulez toujours les relations de modèle d'objet enrichi afin d'écrire une logique métier granulaire. Pour simplifier ce problème, examinons les deux principales lacunes que nous devons combler ... entre la base de données et la couche de base de données/service et le décalage entre le service et le client. NHibernate remplit très bien le premier en fournissant un ORM pour charger des données dans vos objets.Il fait un travail décent, mais pour atteindre de bonnes performances, il doit être modifié en utilisant des stratégies de chargement personnalisées. Je digresse ...
Le deuxième écart, entre le serveur et le client, est là où les choses deviennent risquées. Pour simplifier, imaginez si vous n'avez envoyé aucune entité mappée sur le réseau au client? Essayez de créer un mécanisme qui échange des entités commerciales en objets DTO et de même des objets DTO en entités commerciales. De cette façon, votre client traite uniquement avec les DTO (POCO bien sûr), et votre logique métier peut maintenir sa structure riche. Cela vous permet de tirer parti non seulement du mécanisme de chargement paresseux de NHibernate, mais aussi d'autres avantages de la session tels que le cache L1. Pour des raisons de brièveté et de propriété intellectuelle, je n'entrerai pas dans la conception de ce mécanisme, mais j'espère que c'est assez d'informations pour vous orienter dans la bonne direction. Si vous ne vous souciez pas du tout de la performance ou de la latence ... il suffit de désactiver le chargement paresseux et de résoudre les problèmes de sérialisation.
Si vous êtes vraiment déterminé à transporter le graphe d'objets sur le réseau et à préserver la fonctionnalité de chargement paresseux. Jetez un oeil à un code que j'ai produit ici http://slagd.com/?page_id=6. Fondamentalement, il crée une fausse session de l'autre côté du fil et permet aux proxies nhibernate de conserver leur fonctionnalité. Ne pas dire que c'est la bonne façon de faire les choses, mais cela pourrait vous donner quelques idées.