Le fichier dbml généré par Visual Studio (sqlmetal) est fourni avec des entités mappées aux tables de base de données. Selon vous, ces classes peuvent-elles être utilisées comme classes de modèles de domaines? Ou devrions-nous les éviter et les isoler uniquement dans la couche d'accès aux données?Entités LINQ en tant qu'objets métier - pro/non
Merci
Il dépend
Si vous êtes des objets de domaine sont très simples et votre petit projet, puis en utilisant ces classes n'est pas un problème. Ce serait une perte de temps d'écrire une couche supplémentaire complète qui répète ces classes.
Si les objets sont compliqués et ne mappent pas de façon directe, une autre couche est essentielle pour séparer ces détails de la couche d'accès aux données.
Si vous n'êtes pas sûr, vous pouvez commencer à les utiliser directement, puis ajouter dans un autre calque une fois qu'il est évident que vous en aurez besoin.
Pour une application assez simple, le grand avantage de l'utilisation directe des entités LINQ est - la simplicité. Vous pouvez éviter d'avoir encore un autre calque dans votre code, vous pouvez éviter d'avoir à écrire beaucoup de logique pour mapper votre objet métier à vos entités LINQ (bien qu'il existe des outils comme AutoMapper qui peuvent aider beaucoup ici). D'autre part, comme vous le dites, votre base de données n'est probablement pas une image crachée de votre modèle de domaine. Là encore, si vous avez besoin de cette capacité pour mapper un modèle de base de données physique donné et votre modèle de domaine logique, vous devriez peut-être jeter un coup d'œil à Entity Framework. C'est exactement le pilier de EF - ces deux modèles et la couche de cartographie entre eux.
Marc
+1 pour suggestion d'utiliser Entities Framework. On dirait que c'est peut-être votre allée. – Jagd
Dans la plupart des cas, la couche de bonté sucrée entre les objets d'entité et l'écriture SQL est votre DAL. Le but entier de LINQ est de permettre des constructions beaucoup plus expressives avec votre DAL que ce qui était possible dans le passé.
Sans LINQ, dans votre BL, vous pourriez être limité à des appels de méthode tels que GetCustomersByLastName(string) contre votre DAL. La seule raison pour laquelle vous écrivez cette méthode est parce que quelque part dans votre BL, vous devez obtenir des clients par nom de famille. Cela signifie que vos contrats DAL sont explicitement motivés par les besoins du BL. Alors qu'avec LINQ, vous êtes libéré de la dépendance concrète entre les besoins du BL et les contrats du DAL. Le DAL peut être complètement agnostique quant à l'utilisation spécifique; il expose simplement les contrats des entités et leurs relations, et le BL les utilise à volonté sans se préoccuper de la mise en œuvre de leurs données. C'est vrai séparation des préoccupations.
Si vous cachez la puissance de LINQ derrière une couche DAL traditionnelle, à quoi bon utiliser LINQ?
Je suis totalement d'accord, j'ai rencontré tellement de programmeurs qui voient Linq de la même façon qu'ils ont vu SQL. Ils pensent qu'ils devraient envelopper dans un "DAL" plutôt que de le traiter comme un DAL lui-même! J'espère que les gens commencent à recevoir le message que Linq ** est ** la couche entre votre BL et SQL. –
Je pense que cela dépend de scénarios.
Je suis en train d'écrire un service WCF, mon modèle de données n'est pas très compliqué mais toutes les tables ont des clés étrangères et les relations entre tables font linq créer une arborescence d'objets assez complexe.Du point de vue du client, cela n'a pas de sens d'extraire tout cet arbre d'objets, et le message xml de retour serait assez lourd (donc si je ne change pas la taille maximale du message, je reçois des erreurs).
Dans ce cas, j'ai dû créer des vues personnalisées sur les objets LINQ pour renvoyer uniquement les données que le client s'attend à récupérer. C'est assez pénible car j'ai dû réécrire la plupart des entités mais à la fin j'ai le contrôle total de la communication avec le client.
Vous n'avez pas répondu à votre question? Vous n'avez pas conçu votre base de données pour être un modèle de domaine (j'espère), et ces "entités" correspondent directement à vos tables de base de données, ce qui signifie qu'elles correspondent directement à votre "modèle non domaine". Je considère que c'est une raison pour répondre "non". –
John Saunders, les modèles Entity Framework, contrairement à LINQ to SQL, n'ont pas besoin de (et, en fait, ne devraient généralement pas) être mappés directement au schéma de base de données. –