Meilleures pratiques d'objet de données/Linq

Question

Je suis un nouveau programmeur asp.net et j'ai juste demandé this question qui m'a laissé avec un plus général.

Quelles sont les meilleures pratiques actuelles concernant Linq et les objets de données? Spécifiquement quand à; faible, nouveau et en disposer.

En outre, qu'en est-il des objets qui sont utilisés dans de nombreuses étendues différentes sur la même page, par ex. un objet de données utilisateur. Devraient-ils être au niveau du module ou créés dans chaque portée?

Si quelqu'un pouvait me donner des notes sur les meilleures pratiques actuelles ou même un lien vers un article qui les décrit, je l'apprécierais énormément.

Answer 1

Généralement, vous souhaitez transmettre des données en cours de fonctionnement en tant que paramètres aux fonctions et aux dépendances des types en tant qu'arguments constructeurs. Ainsi, par exemple, un contexte de données linq va probablement être quelque chose dont votre type dépend pour fonctionner, et devrait donc être injecté dans le constructeur. Les valeurs que vous utilisez pour rechercher des données dans votre contexte changeront rapidement et seront utilisées à plusieurs reprises pour le même contexte, et seraient donc des paramètres de fonction sur votre type. Toutefois, si votre type est construit pour effectuer des opérations sur plusieurs contextes au cours de sa durée de vie, vous pouvez envisager de passer le contexte en tant que paramètres de fonction, mais cela indiquerait probablement un problème de conception plus que toute autre chose. En ce qui concerne l'instanciation des contextes de données dans les étendues de fonction d'un type, il n'y a aucune raison d'avoir cette surcharge dans vos fonctions, à moins que la durée de vie de votre type ne soit garantie. Même si c'est le cas en ce moment, il pourrait ne pas être à un certain moment dans le futur et il est donc toujours préférable de concevoir vos types avec cette affaire à l'esprit.

Answer 2

pensées Quickie (je suis assis dans une réunion, si mal moi)

Pour ASP.NET, la durée de vie maximale d'un contexte de données est un poste ou postback. Vous pouvez créer plus que cela, mais ils mourront tous avec le déchargement de la page. Oui, vous devriez en disposer explicitement; l'instruction à l'aide est la meilleure façon de gérer cela parce qu'il appellera automatiquement disposer lorsque le bloc se termine:

using (NorthwindModel nw = new NorthwindModel()) 
{ 
    do stuff 
} 

données qui est revenu d'une requête LINQ ne disparaît pas avec le contexte de données, mais à ce moment-là, il est plus connecté à un contexte et les modifications ne peuvent plus être utilisées pour mettre à jour la base de données. (Vous pouvez toujours créer un nouveau contexte, puis l'attacher en tant que nouvel objet, ou re-interroger et fusionner les modifications, ou tout ce qui répond à vos besoins.)

Soyez très conscient qu'une requête LINQ ne s'exécute pas jusqu'à ce qu'elle ait besoin de évaluer les données. C'est une erreur très facile de garder une requête pendant que le contexte de données est éliminé, puis quand la requête doit s'exécuter, elle ne peut pas, parce qu'elle a été créée avec un contexte de données qui n'existe plus. Il y a deux façons générales de faire face à cela.

1. Traite les résultats de la requête dans le bloc using pour le contexte de données.

2. Force de la requête à exécuter, généralement avec .ToList() ou une autre méthode qui va générer une collecte de données:

   Liste MyCustomers = (de c dans nw.Customers select c).Lister();

Ceci exécute la requête, copie les données dans une collection énumérable et vous donne une collection qui peut être renvoyée à un appelant de méthode. Cependant, ces objets sont maintenant séparés du contexte, ils ne peuvent donc pas être utilisés pour les mises à jour. Si vous faites CRUD avec LINQ, c'est une bonne idée d'utiliser un contexte de données pour toutes les mises à jour, suppressions et insertions, puis appelez SubmitChanges() une fois pour toutes les modifications. Cela garantit qu'ils s'exécutent en une seule transaction. (Le contexte de données génère une transaction pour chaque appel SubmitChanges, si aucune transaction n'est déjà en cours d'exécution.)

Si vous souhaitez sélectionner un élément dans une requête, utilisez FirstOrDefault() plutôt que First(). First() lancera et exception si rien ne remplit les critères de sélection, tandis que FirstOrDefault() retournera une valeur nulle. Très utile à savoir. Au-delà, amusez-vous et essayez beaucoup de choses. LINQ va changer votre façon de penser aux données.