Best practice Data Access Layer

Version imprimable

04/08/2013, 04h19
touftouf57

Best practice Data Access Layer
Bonjour à tous.

Je peine à créer mon Modèle dans une architecture MVP.

Voici l'architecture des objets

Règle
--Colonne [1-n]
--VersionColonne [1-n]
--Cellule [1-n]

Je m’arrête à ce niveau car l'arborescence est longue.

J'ai créé un Modèle RegleModele qui contient la règle courante ainsi qu'un DAORègle qui me permet de faire les opérations CRUD de cette règle.

L'utilisateur peut modifier tous les items de l'arborescence, mais il ne peut faire effectuer que la sauvegarde de la règle.

A savoir:
- les données ne sont pas toutes sur la même base de données.
- C'est une application multi utilisateur, il me faut donc pouvoir gérer les accès concurrentiels.
Pour les accès concurrentiels, j'ai choisi d'utiliser les dataset, puisque les datatables sont capables de gérer ce problème.

Mais comment concevoir mon modèle correctement, puisqu'il me faut une requête SELECT pour que le CommandBuilder puisse créer les requete UPDATE et DELETE de chaque item.

Donc, mon modèle RègleModèle doit il contenir toutes les DAO (DaoColonne, DaoVersionColonne,...)? Solution que je ne trouve pas très "propre".
Ou bien contient-il d'autres modèles (ColonneModèle, VersionColonneModèle,...)? Mais là aussi je ne trouve pas cela très propre, ni simple à coder et à maintenir.:?

Merci de vos conseils. A moins que quelqu'un ai l'adresse d'un bon tutoriel parce que j'ai beau cherché je n'ai pas trouvé grand chose qui m'éclaircisse les idées.
04/08/2013, 10h47
DotNetMatt

Citation:

Envoyé par touftouf57

Pour les accès concurrentiels, j'ai choisi d'utiliser les dataset, puisque les datatables sont capables de gérer ce problème.

Les DataSets, c'est un peu la 2CV du .NET... C'est dépassé quoi :
- C'est verbeux
- Pas très souple
- L'utilisation est assez lourde, en terme de conso ressources
- Les données ne sont pas fortement typées

Bref, rien de tel que des listes d'objets.

Citation:

Envoyé par touftouf57

Mais comment concevoir mon modèle correctement, puisqu'il me faut une requête SELECT pour que le CommandBuilder puisse créer les requete UPDATE et DELETE de chaque item.

Donc, mon modèle RègleModèle doit il contenir toutes les DAO (DaoColonne, DaoVersionColonne,...)? Solution que je ne trouve pas très "propre".
Ou bien contient-il d'autres modèles (ColonneModèle, VersionColonneModèle,...)? Mais là aussi je ne trouve pas cela très propre, ni simple à coder et à maintenir.:?

Pourquoi emploies-tu le terme "contenir" ? Tu dois juste avoir des liens entre tes différents modèles, autrement dit ton RegleModele doit utiliser une instance (ou plusieurs selon le cas) de tes autres modèles.
04/08/2013, 13h33
Invité

Citation:

Envoyé par DotNetMatt

- Les données ne sont pas fortement typées

Les DataSet typés ça existe. :ccool:
04/08/2013, 13h39
Invité
Citation:
Envoyé par touftouf57

les données ne sont pas toutes sur la même base de données.
C'est une application multi utilisateur, il me faut donc pouvoir gérer les accès concurrentiels.
Rien ne t'empêche d'avoir une couche DAL pour chaque base de données.
Si chaque base de données est hébergée par un SGBDR digne de ce nom alors l'accès concurrentiel ne devrait pas être un problème. Sinon les ORM tels que NHibernate, Entity Framework et les outils comme CodeFluent Entities te permettent de gérer l'accès concurrentiels.
05/08/2013, 02h27
touftouf57

Citation:

Si chaque base de données est hébergée par un SGBDR digne de ce nom alors l'accès concurrentiel ne devrait pas être un problème.

C'est bien le problème. Si je fais

UPDATE Regle SET nomRegle="newNom" WHERE idRegle = 124

Et bien il n'y aura aucun accès concurrentiel et ce même si la règle 124 a été modifié depuis Ma lecture.

Citation:

les ORM tels que NHibernate, Entity Framework et les outils comme CodeFluent Entities te permettent de gérer l'accès concurrentiels

L'entreprise dans laquelle je bosse est plutôt frileuse envers ces "nouvelles" technologies.

Citation:

autrement dit ton RegleModele doit utiliser une instance (ou plusieurs selon le cas) de tes autres modèles.

C'est la solution vers laquelle je pensais me tourner. En revanche, cela ne sera pas des Modèles mais des DAO.

Citation:

Pourquoi emploies-tu le terme "contenir"

Quand je dis contenir cela signifie: "Avoir une référence sur une instance de la classe XX". Je sais que ce n'est pas correct sémantiquement parlant, mais c'est plus court.
05/08/2013, 10h03
DotNetMatt

Citation:

Envoyé par h2s84

Les DataSet typés ça existe. :ccool:

Ouais mais bon ça reste quand même un dataset...
05/08/2013, 10h03
meziantou
Citation:

Envoyé par touftouf57

C'est bien le problème. Si je fais

UPDATE Regle SET nomRegle="newNom" WHERE idRegle = 124

Et bien il n'y aura aucun accès concurrentiel et ce même si la règle 124 a été modifié depuis Ma lecture.

Pour faire de la concurrence optimiste il faut ajouter une colonne de type rowversion ou timestamp
http://technet.microsoft.com/fr-fr/l.../ms182776.aspx
Code:

1 2 3 UPDATE maTable SET ... WHERE Id = @Id AND _rowVersion = @_rowVersion
Citation:

Envoyé par touftouf57

L'entreprise dans laquelle je bosse est plutôt frileuse envers ces "nouvelles" technologies.

Ca peut valoir le coup de faire une petite étude sur chacun des produits pour voir ce que ca peut apporter (surtout le dernier :))
05/08/2013, 12h14
Invité

@DotNetMatt,

Citation:

Envoyé par DotNetMatt

Ouais mais bon ça reste quand même un dataset...

Ce n'est pas uniquement un DataSet mais un DataSet typé et les données sont fortement typées donc ce que tu dis ci-dessous est faux.

Citation:

Envoyé par DotNetMatt

- Les données ne sont pas fortement typées

@touftouf57,
La solution proposée par Meziantou est très bien. Pas mal d'ORM utilise cette solution.
05/08/2013, 13h33
DotNetMatt

Citation:

Envoyé par h2s84

Ce n'est pas uniquement un DataSet mais un DataSet typé et les données sont fortement typées donc ce que tu dis ci-dessous est faux.

:aie: Oui ça j'ai bien compris et on est d'accord sur ce point.

Mais ça ne change rien au fait que ça reste un DataSet, et que c'est vieillot et lourd ! Je trouve ça dommage d'orienter un débutant sur l'utilisation des DataSets.
05/08/2013, 15h53
Invité

Citation:

Envoyé par DotNetMatt

ge rien au fait que ça reste un DataSet, et que c'est vieillot et lourd !

Arrête de t'emballer pour un DataSet typé. :aie:

Citation:

Envoyé par DotNetMatt

Je trouve ça dommage d'orienter un débutant sur l'utilisation des DataSets.

Qui est-ce qui a dit, recommandé, conseillé un DataSet (typé ou non) à ce "débutant" dont tu parles ? Ce n'est pas moi. Le message (je dis juste que les données d'un DataSet peuvent être fortément typées pour contredire ton propos) où j'ai notifié l'existence d'un DataSet typé et ma recommandation sont bien distinctes. Ma recommandation, quand à elle, ne porte pas sur un DataSet (typé ou non). D'ailleurs dans mon précédent message je recommande la solution de Meziantou.
08/08/2013, 21h38
ddaime

Citation:

Envoyé par DotNetMatt

Les DataSets, c'est un peu la 2CV du .NET... C'est dépassé quoi :
- C'est verbeux
- Pas très souple
- L'utilisation est assez lourde, en terme de conso ressources
- Les données ne sont pas fortement typées

Désolé de te contredire mais je ne suis pas du tout d'accord avec toi. Les DataSets peuvent être fortement typés et font partis intégrante d'ADO.Net. C'est très simple à mettre en place et à manipuler, très rapide mais manque de fonctionnalités.
09/08/2013, 13h07
DotNetMatt

Oui h2s84 m'a déjà fait remarqué que ça existait...

Bref il n'en reste pas moins le Dataset c'est ce qui existait avant l'apparition des generics dans le .NET 2.0, quand on n'avait pas d'autre choix pour manipuler les données parce que c'était plus complexe de travailler avec les collections.

Oui il y a plus de code à écrire quand on crée des objets custom, mais au final c'est beaucoup plus clair et compréhensible. Chaque classe est taillée sur mesure pour son domaine. On peut l'étendre et réaliser la maintenance plus facilement puisque c'est clairement découpé (chaque classe ayant un rôle bien précis). Alors bien sûr, sur le coup, ça demande plus de boulot donc à court terme c'est consommateur de budget. Mais à moyen/long terme, on y gagne, les coûts de maintenance/évolution étant réduits.

Quand on part avec un DataSet sur une application d'entreprise relativement complexe, c'est sûr qu'au début tout est facile. Puis viens la mise en prod, puis le début de la maintenance et là bonjour la pagaille ! Sur le coup, on ne va rien consommer en terme de budget, mais à moyen/long terme, les coûts vont exploser. C'est l'erreur que commettent de nombreux chefs de projet.

Pour conclure, et je m'arrêterai là, j'assimile le DataSet à un panier : on y met tout et n'importe quoi (des choux, des oeufs, du lapin, des stylos...), sans trop se poser de questions, puisqu'il est polymorphique... Rien n'est donc clairement découpé, la doc sera probablement succinte (ah oui, à quoi bon en faire une, puisque tout est dedans ?)

Donc les DataSets, c'est bien pour des applications simples, ou alors pour prototyper, ou encore si on a une deadline très très courte et qu'on n'a pas le choix. C'est surtout pour du court terme... Pour une application très simple effectivement, ajouter des objets custom peut rajouter de la complexité inutilement, mais pour une application avec un minimum de complexité, il vaut mieux consacrer du temps à créer ses objets custom, et surtout bien réfléchir aux impacts budgétaires.