2010-09-22 12 views
0

Si un projet a utilisé POCO pour des entités et utilise une structure d'entité et utilise un chargement paresseux, alors vous avez un graphique d'objet "incomplet" qui revient sur le réseau. Ainsi, lorsqu'un client utilise l'entité, existe-t-il une sorte de proxy qui chargera automatiquement les valeurs restantes? Devons-nous créer nous-mêmes ce proxy et envelopper l'entité d'origine? Ou existe-t-il un modèle accepté pour identifier les types chargés paresseux qui signaleraient alors au client de faire un autre appel à la WCF?Comment les entités POCO, la structure d'entité et le WCF chargés paresseusement fonctionnent-ils ensemble?

Répondre

1

Utilisez les DTO plats, vous ne voulez probablement pas exposer votre domaine complet au client de toute façon. WCF est basé sur les messages, pas sur le domaine.

2

chargement Lazy avec WCF ne fonctionne généralement pas parce que votre méthode ressemble à:

public List<MyPoco> GetData() 
{ 
    using (var context = new MyObjectContext()) 
    { 
    return context.MyPocos.ToList(); 
    } 
} 

Comme vous le voyez contexte est fermé dans la méthode (vous devez fermer quelque part le contexte). Mais lorsque la liste est sérialisée, elle essaiera de charger les objets dépendants de la charge par défaut = > car le contexte est déjà fermé. En WCF, vous devriez utiliser le chargement impatient.

+0

... et même si le contexte n'était pas fermé, ce serait * encore * une mauvaise idée. Le chargement paresseux est trop bavard pour les objets distribués. –

+0

Le problème que nous avons est que nous avons des comptes avec plusieurs milliers d'éléments de campagne. Nous ne voulons pas sérialiser le problème à moins que quelqu'un ne le demande. – uriDium

+0

Vous avez donc besoin de deux opérations. Un avec des éléments et un sans éléments –