Meilleures pratiques en matière de couche de données

Question

Je suis au milieu d'une "discussion" avec un collègue sur la meilleure façon d'implémenter la couche de données dans une nouvelle application.

Un point de vue est que la couche de données doit connaître les objets métier (nos propres classes qui représentent une entité) et être capable de travailler avec cet objet de manière native.

Le point de vue opposé est que la couche de données doit être indépendante des objets et gérer uniquement des types de données simples (chaînes, booléens, dates, etc.)

Je peux voir que les deux approches peuvent être valables, mais mon propre point de vue est que je préfère la première.De cette façon, si le support de stockage des données change, la couche métier ne doit pas (nécessairement) changer pour s'adapter à la nouvelle couche de données.Il serait donc trivial de passer d'un magasin de données SQL à un magasin de système de fichiers XML sérialisé.

Le point de vue de mon collègue est que la couche de données ne devrait pas avoir à connaître les définitions d'objets, et que tant que les données sont transmises de manière appropriée, cela suffit.

Maintenant, je sais que c'est l'une de ces questions qui ont le potentiel de déclencher une guerre de religion, mais j'apprécierais tout retour de la communauté sur la façon dont vous abordez de telles choses.

AIT

Answer 1

Cela dépend vraiment de votre vision du monde. Avant, j'étais dans le camp des personnes découplées.Le DAL n’était là que pour fournir des données au BAL – point final.

Avec les technologies émergentes telles que Linq to SQL et Entity Framework devenant un peu plus populaires, la frontière entre DAL et BAL est devenue un peu floue.Dans L2S en particulier, votre DAL est assez étroitement couplé aux objets métier car le modèle objet a un mappage 1-1 avec le champ de votre base de données.

Comme pour tout ce qui concerne le développement logiciel, il n’y a pas de bonne ou de mauvaise réponse.Vous devez comprendre vos besoins et vos exigences futures et travailler à partir de là.Je n’utiliserais plus une Ferrari lors du rallye de Dakhar comme je le ferais avec un Range Rover lors d’une journée sur piste.

Answer 2

Vous pouvez avoir les deux.Informez la couche de données de vos objets métier et rendez-la capable de fonctionner avec plusieurs types de sources de données.Si vous fournissez une interface commune (ou une classe abstraite) pour interagir avec les données, vous pouvez avoir différentes implémentations pour chaque type de source de données.Le modèle d’usine va bien ici.

Answer 3

Un excellent livre que j'ai, qui couvre ce sujet, est Modèles d'accès aux données, par Clifton Nock.Il contient de nombreuses bonnes explications et de bonnes idées sur la façon de découpler votre couche métier de la couche de persistance.Vous devriez vraiment essayer.C'est l'un de mes livres préférés.

Answer 4

Jeffrey Palermo a écrit un bon article à ce sujet.Il l'a appelé Architecture de l'oignon.

Answer 5

Une astuce que j'ai trouvée pratique consiste à ce que ma couche de données soit "indépendante de la collection".Autrement dit, chaque fois que je souhaite renvoyer une liste d'objets de ma couche de données, je demande à l'appelant de passer dans la liste.Donc au lieu de ça :

public IList<Foo> GetFoosById(int id) { ... }

Je fais ça:

public void GetFoosById(IList<Foo> foos, int id) { ... }

Cela me permet de transmettre une ancienne liste simple si c'est tout ce dont j'ai besoin, ou une implémentation plus intelligente de IList<T> (comme ObservableCollection<T>) si je prévois de m'y lier à partir de l'interface utilisateur.Cette technique me permet également de renvoyer des éléments de la méthode comme un ValidationResult contenant un message d'erreur le cas échéant.

Cela signifie toujours que ma couche de données connaît mes définitions d'objets, mais cela me donne un degré supplémentaire de flexibilité.

Answer 6

Découvrez Linq to SQL, si je créais une nouvelle application dès maintenant, j'envisagerais de m'appuyer sur une couche de données entièrement basée sur Linq.

En dehors de cela, je pense que c'est une bonne pratique de découpler autant que possible les données et la logique, mais ce n'est pas toujours pratique.Une séparation pure entre la logique et l'accès aux données rend les jointures et les optimisations difficiles, ce qui rend Linq si puissant.

Answer 7

Dans les applications dans lesquelles nous utilisons NHibernate, la réponse devient "quelque part entre les deux", dans la mesure où les définitions de mappage XML (elles précisent quelle table appartient à quel objet et quelles colonnes appartiennent à quel champ, etc.) sont clairement dans le niveau objet métier. .

Ils sont transmis à un gestionnaire de sessions de données générique qui ne connaît aucun des objets métier ;la seule exigence est que les objets métier qui lui sont transmis pour CRUD doivent disposer d'un fichier de mappage.

Answer 8

Ancien message mais je suis tombé sur des informations similaires en recherchant des informations similaires ce ce qui l'explique bien.