Discussion :

[wonderliza]

Voilà, tout est dans le titre. J'aimerai vos retours quand aux DAL que vous avez utilisées pour vos nouveaux projets en 2005.

- une toute faite par vous car besoins spécifiques ?
- une toute faite tout court, genre les applications blocks fournis par MS (patterns and pratices) ex : la CTP de novembre ?

Pouvez vous me faire part de vos retours, et quels choix vous avez faits (et pourquoi) ?

Merci

[neo.51]

Moi j'ai implémenté quelque chose maison que je suis en train de revoir pour .NET 2.0...

Les différents outils que j'ai pu testé m'ont semblé trop complexes et trop long à appréhender. J'ai finalement préféré "perdre" du temps à coder un DAL qui colle parfaitement à mes besoin sans trop de fioritures inutiles.

Je pense que si j'avais du utiliser des framework existant ou des outils de génération de code ça m'aurait au moins pris autant de temps que de coder mon propre DAL.

Une fois codé j'ai un composant simple et léger que je maitrise parfaitement (encore heureux c'est moi qui l'ai fait).

[Louis-Guillaume Morand]

Je pense que si j'avais du utiliser des framework existant ou des outils de génération de code ça m'aurait au moins pris autant de temps que de coder mon propre DAL.

+1. personnaliser quelque chose d'existant ou prendre le temps de le comprendre prend parfois plus de temps que de tout reprendre à zero.

Maintenant, je ne dit pas que la DAL de notre projet est optimisée et la meilleure possible, mais elle est totalement adaptée à nos besoins et une optimisation est prévue en fin de cycle.

[Thomas Lebrun]

Utiliser un générateur, c'est vrai que c'est bien pratique: cela donne un code propre, compréhensible et assez optimisé.

Maintenant, quand tu développes ta propre DAL, tu es sur de ce que tu fais, etc....


Bref, je passe rarement par des générateurs, sauf s'il s'agit d'un gros gros projet

[neo.51]

Au fait, ce choix se justifiait en .NET 1.1 avec VS 2003.

Inutile de dire qu'avec les générics, le générateur de code à partir du diagramme des classes, le binding sur les controle énormément simplifié, etc...

Je commence à voir comment je vais faire mon nouveau DAL et le plus long c'est vraiment la réflexion, pas le temps de codage

Un autre paramètre à prendre en compte, tous mes projets tournent autour d'un même type de base de données avec des opérations qui reviennent souvent sur des "modules" différents à développer(web, reporting, applis windows).

J'ai donc mon DAL fortement lié à la partie metier et DAL + Métier contituent en gros mon framework de dev pour mes applis. En gros je fais que mapper des interfaces graphiques et évoluer mon framework. je préfère donc tout me coder de A à Z.

Sur un gros projet avec des couches bien séparées (encore faut-il qu'il y en ai un interet suivant le contexte) je pense que je regarderais plus sérieusement ce genre d'outils pour générer mon DAL.

[zeavan]

une question peut-etre bete mais mon francais n'etant pas tres riche en vocabulaire technique a dire vrai il ne s'enrichit que chez developpez.com
j'aurai amer connaitre l'equivalence de DAL en anglais.
A moins que le ce soit le meme terme alors la une petite explication serait la bienvenue.

[Thomas Lebrun]

DAL = Data Access Layer = Couche d'accès aux données

[Maniak]

DAL = DataBase Access Layer = Couche d'accès aux données :wink:

Data Access Layer donc :)

Et sinon pour ma contrib : DAL tout à la mano comme neo jusqu'à il y a 6 mois, et maintenant avec NHibernate pour se simplifier *grandement* toute la partie gestion de la base de données. C'est assez rapide à prendre en main et ça permet de se concentrer intégralement sur les données, et plus sur le système de stockage. Très agréable :)

Et vu que ça ne s'occupe que de la base de données, ça laisse totalement libre pour tout le reste. Pi c'est ouvert, répandu, stable et avec un développement actif. Que du tout bon, aucune raison de ne pas en profiter :)

[wonderliza]

merci beaucoup pour vos retours. on s'entend bien que là vous parlez de VS 2005 ? Car je lis des dev qui ont commencé y à 6 mois (ce qui est biensur possible avec les versions bétas) mais je voulais etre sure.
De mon coté, je n'ai pas encore assez de recul pour réfléchir à ce qui convient, il est vrai qu'avec la nouvelle gestion des databinding etc... ca me prendra surement le temps de réaliser un premier projet je pense. Ce sera le 1er projet qui mangera les frais de mon innexpérience sur 2.0 malheureusement

[Maniak]

merci beaucoup pour vos retours. on s'entend bien que là vous parlez de VS 2005 ? Car je lis des dev qui ont commencé y à 6 mois (ce qui est biensur possible avec les versions bétas) mais je voulais etre sure.

2003 ou 2005, ça n'a aucun impact sur le choix de la méthode pour faire le DAL (du moins pour moi :)

.NET 2.0 facilite les choses pour faire les classes avec l'arrivée des templates. À part ça, c'est tout pareil. L'accès à la base est toujours géré par NHibernate et le code ne touche qu'aux classes elles-mêmes. Et le databinding n'a aucune influence là-dessus. Raison toute bête : le DAL est la couche la plus basse du code. L'interface est la couche la plus haute. Entre les deux, il y a la couche métier. Du databinding qui lie directement la couche d'interface à celle des données, j'en veux pas :)

[Thomas Lebrun]

DAL = DataBase Access Layer = Couche d'accès aux données

Data Access Layer donc

Faute de frappe corrigé, merci

[wonderliza]

Maniak, pour moi de passer à 2005 changait un peu les choses : j'en profitais pour refléchir à nouveau et eventuellement remettre en cause mes anciens choix.
Je comprend que tu ne veuilles pas binder directement à l'UI tes données depuis la DAL en direct, mais en fonction des divers projets, parfois la BL n'a vraiment aucune raison d'etre

Le soucis, c'est que je n'ai pas UN gros projet qui evolue, mais je recommence un nouveau projet totalement différent tous les 3/4 mois.

Bon, ben merci en tout cas. Après avoir fait quelques essais sur divers projets, je viendrai surement donner mon retour.

elise (coucou néo )

[zeavan]

merci pour l'info.

[neo.51]

En tous cas moi je viens de trouver un généric bien sympas qui permet de profiter de toutes les fonctionnalités de binding de VS 2005 sur une collection d'ojets métiers : http://www.gotdotnet.com/workspaces/workspace.aspx?id=ccbb6b50-6c55-4291-b191-f5c5f80ba122

En gros on fait des vues sur une BindingList, des vue qui ressemblent à des dataview et ces vues on peut directement les mettre en dataSource du BindingSource.

Dans ce contexte on peut dire que VS 2005 et .NET 2.0 changent considérablement la donne

[wonderliza]

oui justement, ca me choque.
en principe, on peut faire ça, dans la page :

<asp:sqldatasource id="MySource" runat="server"
ProviderName="System.Data.SqlClient"
ConnectionString="<%$ ConnectionStrings:NWind %>"
SelectCommand="SELECT * FROM employees">
<asp:repeater runat="server" id="Repeater1"
DataSourceId="MySource">

ce qui veut dire, mettre de l'accès aux données directement dans la page. Et utiliser cette source apres pour les grilles and co....

ca me choque ! quand on lit les docs de MS, qui ont été écrites y a un bail, genre sur pattern and practices, là où MS donne ses guidelines, ses conseils en matiere de "comment bien coder", il est bien spécifié d'on sépare les données de la présentation !!

et là, pour asp.net 2005, les nouveautés vont complètement à l'opposé... à moins que j'aie loupé quelque chose au passage ??? :

[Maniak]

et là, pour asp.net 2005, les nouveautés vont complètement à l'opposé... à moins que j'aie loupé quelque chose au passage ??? :?:

Non non, c'est tout à fait habituel chez MS.

D'un côté, des guidelines sur les bonnes pratiques à appliquer, généralement récupérées d'ailleurs, compilées et parfois retraitées à leur sauce. Y a qu'à voir la présentation du TDD-selon-MS.

De l'autre côté, un gros projecteur sur les méthodes 'bourrin', 100% assistées par les magnifiques assistants fournis de base avec VS.NET. Et là, bonjour les liaisons directes données-interfaces, l'éclatement complet de la séparation en couches et de toute autre forme de séparation d'ailleurs. On a un code super modulable quand on se laisse guider par les assistants. Les pages web créent les connexions SQL, les datasets typés se repèrent aux noms de champs et de tables et sont directement plaqués dans les contrôles web, que du bonheur.

Il y a grosso modo deux versions de MS quand il s'agit du développement. Une version est assez orientée bonnes pratiques, design propre, patterns, tout ça, et s'adresse aux développeurs... comment dire... 'expérimentés' n'est pas loin mais pas tout à fait, 'compétents' est plus proche mais pourrait froisser des âmes sensibles... disons que ça s'adresse aux développeurs qui s'intéressent au développement et qui ont envie d'apprendre et de s'améliorer. Des développeurs quoi. Des gens qui développent des applications pour les autres.

L'autre version s'adresse aux... euh... certains les appellent encore 'développeurs' alors qu'ils se fichent complètement de la qualité du développement et qu'ils ne cherchent qu'à se simplifier la vie au maximum. Des bidouilleurs. Des gens pour qui leur confort est la priorité n°1, et le confort des autres passe après. Pour ceux-là, allez hop, qu'on colle des connexions au milieu du HTML, pas de problème, on s'en fout, c'est la fête, go go go.


Moralité, ça vaut pour tout mais *particulièrement* pour .NET et encore plus particulièrement pour VS.NET : attention, c'est pas parce qu'il y a des nouveautés qu'il faut y toucher. Il faut faire un gros tri d'abord. Les nouveautés qui vont à l'encontre d'un développement 'propre' et qui ne sont faites que pour simplifier la vie des bidouilleurs et autres pseudos-développeurs, il ne faut pas avoir de scrupules à les mettre à la poubelle. Pas de scrupules et pas d'hésitation non plus. Et les nouveautés en question peuvent être nombreuses...


C'est particulièrement pratique quand il faut donner des conseils aux 'débutants'. Vas-y pour les convaincre de faire plein de classes, de bien séparer les responsabilités, de limiter les dépendances entre les modules, quand ils ont un outil qui fait flasher en gros sur la moitié des fenêtres "pour afficher des données sur cette page, cliquez ici et faites glisser là". Tu leur expliques qu'il ne faut pas, que la séparation des responsabilités est une priorité, tout ça, "oui mais si ce n'était pas bien, pourquoi est-ce que ce serait si facile de le faire avec VS.NET ?"
Oui, pourquoi ? La question s'adresse à MS.

[wonderliza]

merci pour ta vision, elle m'eclaire un peu.
JE sais que 2005 n'est pas nouveau, mais moi, j'avais un peu laissé tout ca de coté, et je "découvre" en détail ca depuis lundi... et me voila pleine de question existentielles.
ca me rassure, finalement, ta vision des choses.

elise

[Pierre Henri Kuate]

Hum...

Donnez moi un peu de temps, et je vous convertirais tous au Mapping Objet / Relationnel (NHibernate)

(avec l'aide de Maniak... ça c'est un nom qui dit tout )

[Maniak]

(avec l'aide de Maniak... ça c'est un nom qui dit tout :wink: )

Vu que j'en suis encore à un stade d'utilisation relativement basique (mais suffisamment pour avoir perdu toute envie de refaire ça à la main un jour :), si tu es plus avancé dedans, c'est surtout toi qui devra faire le boulot :)