NHibernate & WCF en version 3.0

Question

Je viens de démarrer un nouveau projet qui nécessite un service WCF pour gérer un environnement distribué. J'essaie toujours de trouver la meilleure façon de mettre en œuvre les choses. Je veux utiliser NHibernate, mais j'ai vu plusieurs façons de traiter la sérialisation. Est-ce géré dans 3.0? J'ai remarqué wcf_context à l'intérieur du camion: D

S'il n'est pas manipulé, quelqu'un pourrait-il me pointer dans la bonne direction?

Merci à tous

Answer 1

Vous ne pouvez pas passer l'objet Lazy chargé à l'aide WCF.

il y a des façons de contourner, mais il y a un bug qui sera corrigé dans la prochaine version WCF (à venir bientôt, avril 2010)

Autre que cela, ils laissent joyeusement ensemble, aussi longtemps que vous définissez les objets avec le droit DataContract. Il y a aussi un problème de sérialisation des listes - Vous devez générer le proxy en utilisant svcutil avec un certain drapeau ou de mauvaises choses arrivent (les listes deviennent des tableaux et vous ne pouvez pas ajouter plus d'éléments) (sauf si vous utilisez un certain type de liste que WCF et NHibernate sont d'accord) - regardez ça (listes Nhiberate et WCF) -

Answer 2

Généralement, si vous allez retourner des données d'un service, vous voudrez retourner une classe spécifique dans le but du service, contenant ce qui est pertinent pour cet appel de service, un objet DTO (Data Transfer Object) ou DataContract dans le monde WCF.

Un outil particulièrement utile pour le mappage entre entités et DTO est AutoMapper. Que vous utilisiez AutoMapper ou simplement un codage «gauche-droite», cela évitera le chargement paresseux/l'exécution différée car le mappage provoquera l'exécution.

Il y a un certain nombre de raisons pour lesquelles il pourrait ne pas être une bonne idée de retourner une entité d'un service, voici quelques-unes (il y a des opinions différentes sur la plupart de ces)

• En fonction de votre persistance (dans votre cas nhib) vous pouvez avoir un comportement (exécution retardée) ou un état attaché à vos entités qui ne s'exécuteront pas correctement dans une autre application ou un autre serveur
• Les résultats d'une entité de retour dans une couche de service entraînent souvent des appels qui sont très CRUD- comme, résultats dans une couche de service très bavard, et très un-SOA
• Différents appels pourraient nécessiter plus ou moins de données que juste ce qui est une entité, un DTO vous donne la possibilité de conclure exactement ce dont vous avez besoin, et rien que vous n'avez pas.
• Si vous essayez de créer une couche de service réutilisable, vous ne devez pas supposer que vos clients ont accès à votre logique d'entité ou de domaine autre que celle de votre service. ils pourraient être écrits dans une autre application, une autre langue, etc. Si vos entités sont ce que vous utilisez pour déplacer des données, vous aurez tendance à oublier cela.