WCF Linq2SQL ne retourne pas les objets "Parent"

Question

J'ai un service WCF qui récupère des données via Linq2SQL. Je reçois tous les enregistrements enfants, mais pas les enregistrements parent correspondants

i.e L'enregistrement client a des commandes liées, et il y a un statut sur le client. Je reçois le client et les commandes, mais je ne peux pas obtenir l'enregistrement d'état pour obtenir la description de l'état

using (MyDataContext context = new MyDataContext(CommonCode.DBConnectionString)) 
     { 
      context.DeferredLoadingEnabled = false; 
      DataLoadOptions options = new DataLoadOptions(); 
      options.LoadWith<Customer>(u => u.Orders); 
      options.LoadWith<Customer>(u => u.CustomerStatus); 

      context.LoadOptions = options; 
      context.ObjectTrackingEnabled = false; // retrieving data read only 

      return context.Customers.SingleOrDefault<Customer>(
       cus=> cus.CustomerId == passedId); 
     } 

J'ai essayé de jouer avec le chargement différé et de suivi d'objets (que je ne ai pas besoin sur) et sont en cours d'exécution à partir d'idées.

Quelqu'un peut-il aider sur la façon dont je peux retourner l'enregistrement du statut du client s'il vous plaît.

Answer 1

J'ai découvert ce que c'était! Linq to SQL mettra l'attribut [DataMember()] sur les enregistrements enfant, mais pas les parents. J'ai dû ajouter l'attribut [DataMember()] sous l'association.

L'inconvénient est que c'est une entrée manuelle aux context.designer.cs qui seront écrasés si le dbml change :-(

[Association(Name="CustomerStatus_Customer", Storage="_CustomerStatus", ThisKey="CustomerStatusId", OtherKey="CustomerStatusId", IsForeignKey=true)] 
    [DataMember()] 
    public CustomerStatus CustomerStatus 
    { 
     get 
     { 
      return this._CustomerStatus.Entity; 
     } 
     set 
     { 
      ... 
     } 
    } 

Answer 2

Cela ne répond pas vraiment à la question (ennuyeux je sais!) Mais peut-être est-il préférable de définir des objets personnalisés dans vos contrats de données et de les remplir manuellement pour passer le service. De cette façon, si vous changez votre modèle Linq2Sql vous ne casserez pas votre client WCF.

En outre, ce n'est pas aussi long que cela puisse paraître. En Linq2SQL vous pouvez quelque chose comme ..

from c in context.Customers 
where (...) 
select new CustomerStatusRecord() { CustomerId = c.Id, Status = c.CustomerStatus.Status ... } 

CustomerId et le statut sont les champs dans votre contrat de données nouvellement défini.

Cette méthode de découplage serait ma façon préférée de le faire, mais je comprends pourquoi, par commodité, il est plus facile de passer l'ensemble de l'objet de contexte de données sur le service. Dernière réflexion: Si, dans le futur, vous ajoutiez 50 nouveaux champs impairs à la table client, l'utilisation de la manière que vous avez décrite augmenterait réellement le transfert de données dans votre service. Toutefois, si son découplé, vous avez un contrôle absolu sur ce qui se passe sur le fil. Si vous le laissez tel quel, vous risquez de transmettre des données sensibles.