Préchargement de données dans Linq-to-SQL, modèle IOC et référentiel

Question

utilisant Linq-to-SQL, je voudrais pré-extraire certaines données.

1) La solution commune consiste à traiter les options de chargement de données , mais cela ne fonctionne pas dans mon architecture, car:

• les options doivent être définies avant la première requête
• J'utilise IOC, je n'instancie donc pas directement le DataContext (je ne peux pas exécuter de code à l'instanciation)
• mon DataContext est persistant pendant la durée d'une requête Web

2) J'ai vu une autre possibilité basée sur le chargement des données et de leurs enfants dans une méthode, puis en renvoyant uniquement les données (le fils est donc déjà chargé) < un href = "http://www.west-wind.com/weblog/posts/38838.aspx" rel = "nofollow noreferrer"> voir un exemple ici

Néanmoins, dans mon architecture, cela ne peut pas ne pas fonctionner:

• Mes requêtes sont mises en cascade hors de mon référentiel et peuvent être utilisées par de nombreux services qui ajouteront des clauses
• Je travaille avec des interfaces, les instances concrètes des objets linq-to-sql ne quittent pas les référentiels (oui, vous pouvez travailler avec des interfaces ET ajouter des clauses)
• Mes référentiels sont génériques

Oui, cette architecture est assez compliquée, mais c'est très cool car je peux jouer avec le code comme lego;)

Ma question est la suivante: quelles sont les autres possibilités de pré-télécharger des données?

Answer 1

Dans mon application, j'utilise peut-être une variante de votre solution potentielle n ° 2. C’est un peu difficile à expliquer, mais simplement: i enchaîner et différer le chargement paresseux dans mon modèle avec la coutume classes paresseuses afin de faire abstraction de l’exécution différée spécifique à LinqToSql dont je tire parti avec IQueryable . Avantages:

• Mon modèle de domaine et ma couche de service ne doivent pas nécessairement dépendre du fournisseur LinqToSql (je peux échanger mon DAL avec des interfaces si je le souhaite)
• Mes méthodes de service peuvent renvoyer et renvoient des graphiques d'objet complets avec plusieurs "points d'ancrage" pour le chargement différé à l'aide de classes décrivant en détail une implémentation particulière du chargement différé. Ainsi, je peux utiliser l'exécution différée spécifique à LinqToSql ou autre chose (par exemple, des délégués anon Encore une fois, reportez-vous à cette réponse )
• Je peux conserver des résultats IQueryable dans mon application (même à l'interface utilisateur si je le souhaite), permettant ainsi un enchaînement infini de requêtes LINQ sans avoir à se soucier des performances.

Answer 2

Je ne suis pas au courant d'autres possibilités, il semble que vous ayez poussé LinqToSql à ses limites (je peux toutefois me tromper).

Je pense que vos meilleures options à ce stade sont les suivantes:

1. Ajouter des " non génériques " méthodes à votre application pour gérer uniquement la scénarios spécifiques où vous voulez / avez besoin d'un chargement rapide et ne le faites pas utilisez votre " normal " ;, & générique " infrastructure pour ces méthodes.
2. Utilisez un ORM offrant un support plus sophistiqué pour un chargement rapide et paresseux.

Answer 3

J'ai trouvé une solution. Ma réponse est " Injection de dépendance ".

Il est généralement livré avec IOC et signifie que votre conteneur IOC peut gérer l’injection de classes à l’instanciation.

Il suffit d’injecter une classe CustomDCParameter lorsque j’instancie un contrôleur de domaine. Cette classe contiendra les règles et le constructeur les appliquera toutes.