Dans quels scénarios voudrais-je créer des objets métier personnalisé de Linq aux résultats Sql?

Question

Une simple requête SQL à LINQ peut renvoyer un objet produit. Obiously je pouvais passer cet objet à ma couche d'affaires, puis lire et mettre à jour les données, directement sur cet objet.

J'ai vu un tas d'implémentations où après l'exécution de la requête LINQ l'objet résultant est mis en correspondance (via automapper ou manuellement) à un objet métier personnalisé. Ainsi, dans le cas du produit où je pourrais avoir l'objet LINQ:

Produit.IDProduit et Product.ProductName

et puis je définir un objet métier de produit personnalisé comme ceci:

class BusineszProduct
{
    string ProductId;
    string ProductName;
}

et un code de mappage simple comme:

BusinessProduct myProduct = new BusinessProduct (); myProduct.ProductId = Produit.IDProduit; myProduct.ProductName = product.ProductName;

puis passer myProduct autour de ma couche métier, modifier, lire et ainsi de suite, puis mettre à jour plus tard l'objet LINQ.

Dans quels scénarios voudrais-je créer la classe BusinessProduct personnalisée?

Answer 1

à mon humble avis, la raison générale est de découpler / vos entités démêler des affaires de l'Linq2SQL bagages ORM qui vient avec les entités linq2sql

Cependant, dans un scénario extrême, vous pouvez avoir plusieurs applications:

• entités linq2sql pour la couche "Data Access" - mais ceux-ci sont étroitement couplés au L2S DataContext
• Poços / entités d'affaires seraient utilisés pour l'application de règles métier, validation etc
• Si vous utilisez les services Web ou WCF, vous pourriez représenter également les données en tant qu'entités message par exemple si vous avez besoin de présenter les entités dans un format très spécifique lorsqu'ils sont sérialisés à travers le fil
• Et enfin, si vous avez une architecture MVC UI / MVP / MVVM, vous voudrez peut-être des entités sur mesure pour votre point de vue

Answer 2

Dans ma demande, je fais une requête Linq qui réunit six tables différentes, et fournit un couple de colonnes de chacun. Il n'y a pas de type objet spécifique-table qui correspond à cet ensemble d'informations. D'où je crée une classe d'affaires personnalisé pour gérer le jeu d'enregistrements.

Vous pouvez voir vous-même ( http://www.njtheater.org )

Je sélectionner à partir de la table de Productions par date. Il se joint à la table de lecture (où je reçois le titre et description), la table Troupes (où je reçois le théâtre nom de l'entreprise), la table Venues (où je reçois le nom de théâtre & City). Le tableau Plays joint à la table PlayCredits qui se joint à la table Les gens (où je reçois les noms des auteurs dramatiques)