2011-03-23 4 views
2

J'ai un modèle de données pour Entity Framework dans lequel certaines entités ont une collection d'attributs qui peuvent être utilisés pour ajouter des informations supplémentaires. Certains clients souhaiteraient mapper ces attributs aux propriétés «réelles» de leur propre modèle de domaine. Un exemple-modèle de données est:Mappage Linq entre modèles

public class DataEntity { 
    public Guid Id { get; set; } 
    public virtual ICollection<Attribute> Attributes { get; set; } 
} 
public class DataAttribute { 
    public Guid Id { get; set; } 
    public String Name { get; set; } 
    public String Value { get; set; } 
} 
public class DataStringAttribute : DataAttribute { 
    public String Value { get; set; } 
} 
public class DataInt32Attribute : DataAttribute { 
    public Int32 Value { get; set; } 
} 

Et un domaine-modèle exemple:

public class DomainEntity { 
    public Guid Id { get; set; } 
    public String Name { get; set; } 
    public Int32 Age { get; set; } 
} 

je peux carte assez facilement les entités entre eachother, mais je voudrais être en mesure de cartographier les expressions Linq entre les deux pour que dans le client, il serait IQueryable<DomainEntity>, mais cela est mis en correspondance IQueryable<DataEntity> - par exemple:

myDomainEntities.Where(o => o.Age > 21) 

pourrait être mis en correspondance:

myDataEntities.Where(o => o.Attributes.OfType<DataInt32Attribute>() 
    .Any(o => o.Name = "Age" && o.Value > 21); 

Quelle serait la meilleure façon de le faire - peut-être écrire un QueryProvider qui marche l'arbre d'expression et traduit à celui qui utilise le modèle de données - un Linq-à-Linq-à-EntityFramework?

Merci.

Répondre

0

Ce que vous essayez de faire est atypique. Vous devrez peut-être remplacer le fournisseur Linq-to-Entity et remplacer sa fonctionnalité de génération de requête. Vous parcourez vous-même l'arbre d'expression, puis convertissez dynamiquement cet arbre d'expression en une nouvelle arborescence avec laquelle Linq-to-Entity peut travailler, puis transmettez cette arborescence au fournisseur d'origine pour la génération de la requête. En d'autres termes, vous détournez Linq-to-Entity pour prendre en charge votre format personnalisé. Poilu, mais si vous le faites fonctionner, s'il vous plaît écrivez à ce sujet! Je serais heureux d'apprendre comment cela fonctionne!

En outre, vous comprenez que votre client ne bénéficiera pas de la prise en charge d'Intellisense, à moins que vous n'écriviez également un plug-in personnalisé pour VS. Le code sera également marqué comme erreurs de syntaxe dans VS (je ne suis pas sûr qu'il compilera). C'est parce que les définitions de classe n'ont pas vraiment changé - les entités n'ont pas vraiment ces propriétés.

+0

Je pense que l'appoach - même si c'est beaucoup de travail - pour créer un fournisseur de requête intermédiaire fonctionnerait et serait compilable. Performance sage, ce ne serait probablement pas génial. Je me demande simplement s'il y a d'autres options, et si quelqu'un a essayé cela. –

+0

Je ne pense pas que quiconque a essayé cela, du moins pas en connaissance de cause. Cependant, faites attention à ce que VS les signale comme des erreurs - vous réécrivez l'arbre d'expression pour convertir l'erreur en erreur, mais VS ne le sait pas. Il peut les signaler tous comme des erreurs et refuser de compiler. –