2010-05-11 14 views
1

Il y a beaucoup de messages sur la façon dont les objets POCO sont cool et comment Entity Framework 4 les prend en charge. J'ai décidé de l'essayer avec une architecture orientée domaine orientée développement et fini avec les entités de domaine qui a des dépendances de services. Jusqu'ici tout va bien. Imaginez que mes produits sont des objets POCO. Quand je requête pour des objets comme celui-ci:Existe-t-il un moyen de fournir une fabrique personnalisée pour les entités de création de .Net Framework à partir d'EF4?

NorthwindContext db = new NorthwindContext(); 
var products = db.Products.ToList(); 

EF crée des instances de produits pour moi.

Maintenant, je veux injecter des dépendances dans mes objets POCO (produits) La seule façon que je vois est de faire une méthode au sein NorthwindContext qui fait quelque chose comme pseudo-code ci-dessous:

public List<Product> GetProducts(){ 
    var products = database.Products.ToList(); 
    container.BuildUp(products); //inject dependencies 
    return products; 
} 

Mais si je veux pour rendre mon dépôt pour être plus flexible comme celui-ci:

public ObjectSet<Product> GetProducts() { ... } 

Alors, j'ai vraiment besoin d'une usine pour le rendre plus paresseux et LINQ amical. S'il vous plaît aider!

Répondre

3

Cherchez-vous le mot-clé yield?

public IEnumerable<Product> GetProducts() 
{ 
    foreach(var product in database.Products) 
    { 
     yield return container.BuildUp(product); 
    } 
} 

- 2ème tentative:

public IEnumerable<Product> BuildUp(this IEnumerable<Product> source) 
{ 
    foreach(var product in source) 
    { 
     yield return container.BuildUp(product); 
    } 
} 

Utilisation:

database.Products.Where(p => blah).BuildUp(); 
+0

Merci pour votre variante! Eh bien, imaginez que j'ai 1000 produits et au moins la moitié d'entre eux va charger en mémoire sur base de données de requête simple.Produits.Where (x => x.Id == 50); Et je devrais dire au revoir à .Inclure (...) syntaxe de requête – IlliakaillI

+0

J'ai mis à jour la réponse, cela devrait réduire les charges inutiles –

+0

:) ok, cela fonctionne pour moi. Donc, si une telle usine n'existe pas dans cette version de EF - je considérerai cette réponse comme acceptée. Merci vanja! – IlliakaillI

0

La réponse est que vous ne devriez pas injecter des services dans vos entités. Le raisonnement derrière cette réponse peut être trouvé sur Jimmy Bogard's blog, ainsi que on my own one.

Il y a beaucoup de problèmes, y compris:

  • confusion sur les méthodes utilisent la dépendance injectée
  • différents cycles de vie des entités et services
  • difficultés dans les tests
+0

Merci Szymon de regarder mon message! Je commence seulement à créer de l'architecture dans un domaine-design, avant que j'utilise mon intention de préférence. Maintenant, j'ai la chance d'introduire un peu de conceptualité dans mes créations, de nommer et d'organiser les choses correctement et ainsi de suite. Les problèmes avec les dépendances sont la plupart du temps des mensonges dans la conception qui rend l'entité responsable de choses conceptuellement différentes. Nous supprimons tous la logique de persistance des entités parce que ce n'est pas le but de l'entité elle-même, n'est-ce pas? Alors, pourquoi ne pas laisser une logique homogène à l'intérieur? – IlliakaillI