Transfert d'objets de données LINQ

Question

Je travaille sur un webservice où nous utilisons LINQ-to-SQL pour notre abstraction de base de données. Lorsque les clients utilisent notre webservice, les objets sont sérialisés en XML et tout est dandy.

Maintenant, nous souhaitons développer notre propre client qui utilise les types de données natifs car il n'y a aucune raison de faire des objets-> xml-> objets. Cependant, d'après ce que je comprends, vous ne pouvez pas transférer les objets LINQ car ils sont directement mappés à la base de données et, par conséquent, les données sont "en ligne".

Ma question est de savoir s'il existe un moyen de prendre un «instantané» des données que vous avez extraites, de définir l'objet LINQ sur «hors ligne», puis de le transférer. Les données ne changeront pas après leur transfert à notre client et nous n'avons pas besoin de l'accès à la base de données.

Answer 1

Si vous souhaitez utiliser WCF (pour le webservice et le client), vous pouvez décorer vos classes générées Linq2SQL avec les attributs [DataContract] et [DataMember].

Vérifiez les liens suivants pour quelques conseils:

• http://msdn.microsoft.com/en-us/library/bb546184.aspx
• http://msdn.microsoft.com/en-us/library/bb546185.aspx
• http://www.codeproject.com/KB/WCF/LinqWcfService.aspx
• http://www.aspfree.com/c/a/Windows-Scripting/Designing-WCF-DataContract-Classes-Using-the-LINQ-to-SQL-Designer/

Answer 2

Les classes LINQ to SQL peut être utilisé avec DataContractSerializer (pour WCF) assez facilement (vous devez Activez la propriété de sérialisation dans le concepteur, cependant). Avec cela en place, vous devriez être en mesure de partager l'assemblage de données avec le client. Tant que vous n'utilisez pas le contexte de données, les objets eux-mêmes devraient bien se comporter (juste déconnectés - donc pas de chargement paresseux).

L'astuce est que vous devez réutiliser ces types (de l'assembly existant) dans votre code de sérialisation. Si vous utilisez WCF, vous pouvez le faire avec svcutil /r, ou via l'IDE.

Cela dit cependant; Il est souvent plus propre de maintenir des classes DTO distinctes pour ces scénarios. Mais je suis coupable de le faire de la manière ci-dessus à l'occasion.