Où les ensembles de données doivent-ils résider dans une architecture à plusieurs niveaux (multi-couches)?

Question

Nous discutons actuellement de la question de savoir si un jeu de données doit aller dans la couche données ou dans la couche de gestion

Mon ami pense que tous les composants ADO.NET devraient être placés dans la couche de données. Pour moi, cela ne semble pas correct pour les raisons suivantes:

• Si vous créez un client de couche de données volumineux, il sera beaucoup plus difficile de tout migrer, par exemple, vers une autre source de données.
• Vous ne pouvez pas avoir de contrôles liés sauf si vous ignorez la logique de la couche de gestion.

Je pense que les jeux de données et les tables de données doivent être dans la logique métier car ils sont génériques pour tous les fournisseurs de données. La couche de données doit avoir une fabrique de fournisseurs pour instancier les objets du fournisseur approprié (Connexion, DataAdapters, Transactions, DataReaders, etc.). Pour moi, c’est la voie à suivre pour les raisons suivantes:

• La migration vers une autre couche de données est aussi simple que possible.
• Vous pouvez lier vos contrôles à des objets métier riches

Un gourou de niveau supérieur peut-il nous aider à déterminer la voie à suivre? Merci d'avance

Answer 1

Là où je suis, nous renvoyons des jeux de données, des tables de données, des datarows et des datareaders de la couche de données à la couche de gestion.

La raison en est que ces types ne sont pas spécifiques à db-flaveur. Que vous utilisiez mysql, access, serveur SQL, Oracle ou tout autre jeu de données est un jeu de données, vous pouvez donc renvoyer depuis une couche de données de niveau racine.

Une couche de gestion prend ensuite ces données brutes et les transforme en objets de gestion fortement typés & # 8212; appliquer les règles commerciales nécessaires & # 8212; remettre à la couche de présentation.

Modifier : lorsque j'examine certains codes, nous n'utilisons pas beaucoup de données complètes. Il s’agit principalement de datatables et de datareaders.

Answer 2

À mon avis, n'utilisez pas du tout DataSet. N'utilisez même pas DataSet dactylographié. Ce sont d'anciennes constructions créées avant LINQ. Passez au-dessus de l'histoire ancienne et entrez dans le présent: utilisez LINQ to Entities et le Entity Framework (EF). Les deux sont étroitement liés mais pas les mêmes.

N'exposez pas une entité EF au-delà d'une limite de service. Malheureusement, Microsoft a choisi d'exposer les détails de l'implémentation lors de la sérialisation d'une entité. En dehors de cela, utilisez EF et amusez-vous beaucoup plus qu'avec DataSet.

Answer 3

Eh bien, isoler l'accès aux données n'est pas nouveau: nous le faisons il y a 15 ans (oui, il y a 15 ans!).

J'ai travaillé dans de nombreux endroits et j'ai vu beaucoup de couches de données isolées.

Mais je n'ai jamais - jamais! - vu une source de données remplacée!

Oui, je l'ai vu deux fois: et deux fois, nous remplaçons également la couche de données obsolète et tous les logiciels de toping ...

Ma réponse est assez simple: si vous ne travaillez pas avec des logiciels de shelve, vous pouvez isoler autant que vous le souhaitez la couche de données, vous le ferez pour rien.

Pour rien car personne ne changera SQL Server ou Oracle juste pour changer. Et pour rien parce que le jour où quelqu'un le fera, soit ils réécriront également leurs logiciels, soit ils veilleront à ce que le produit qu’ils achètent soit compatible avec le produit qui leur reste.

Dans mes livres, toute couche de données est stupide.

Si vous n'acceptez pas cela, dites-moi quand dans votre vie cette couche sauvera $$$ de quelqu'un ...

Answer 4

Une approche typique consiste à exposer une interface de référentiel racine agrégée (telle que Client) dans votre couche / domaine de logique métier et à mettre en œuvre les référentiels concrets dans votre couche / infrastructure d'accès aux données.

Answer 5

Le problème fondamental que j'ai avec DataSets est que leurs structures sont un miroir exact du schéma de base de données.

Si vous exposez le DataSet au code de rendu de page réel, vous exposez effectivement le schéma de base de données (le backend ultime du produit) à la couche de présentation. Le problème évident peut maintenant se produire: vous souhaiterez ultérieurement restructurer le schéma de données sous-jacent et, en raison de la conception, vous devrez appliquer des modifications à toutes les autres couches du système. C’est un excellent exemple d’encapsulation qui n’est pas utilisée alors qu’elle devrait l’être.

Si vous envisagez d'utiliser des ensembles de données, conservez-les dans la couche d'accès aux données et exposez un ensemble conceptuel d'objets métier à la couche de présentation. L'ensemble d'objets de gestion que vous exposez doit être conçu selon de bons principes orientés objet, ce qui est complètement différent d'un bon principe de conception de base de données relationnelle.

Answer 6

Je suis d’accord pour ne pas utiliser de ensembles de données. L'une des applications sur lesquelles j'ai travaillé était les DataSets à la fois dans la couche de données et dans la couche d'application. Les DataLayer DataSets correspondaient à la base de données où les jeux de données de la couche Application ont dénormalisé les informations pour les rendre plus utilisables pour le client.