Discussion :

[Yogy]

Bonjour,
je viens vers vous car je dois mettre mes yeux dans un projet dotnet en c# qui a été développé pour nous par une société de services.
On m'a demander de regarder ce qui pouvait me 'choquer'.
Le truc le plus bizarre est que je vois des acces directs depuis l'interface à la couche d'accès aux données.
Qui plus est j'ai beau regarder je ne vois pas vraiment de couche Métier avec les regles de gestion etc..(il y en a bien une objet métiers par contre).
Est-ce normal, enfin est-ce une pratique courante ?
Merci par avance pour vos éclairages !!

[Gold Bug]

Effectivement, j'aurais tendance à dire qu'une couche de présentation qui effectue des connexions directes à la base de données c'est mal !
Donc je suis d'accord avec toi sur ce point.

Ensuite, concernant l'audit pur et dur d'assemblies .NET, tu peux utiliser l'outil (gratuit) FxCop.

[Keihilin]

Est-ce normal, enfin est-ce une pratique courante ?

Non, ce n'est pas une pratique courante étant donné le nombre d'équipes qui suivent religieusement les recommandations usuelles.

Tout cela pour se retrouver au final avec une couche qui va chercher des données, une couche qui va faire du mapping dans tous les sens pour construire des objets et une couche qui va faire le travail inverse pour afficher ces objets sans qu'aucune valeur n'ai été ajoutée entre la base de données et l'écran...

Tout ça pour dire que la description que tu en fais indique, à priori, qu'il y a effectivement un problème de découpage et d'organisation, mais en l'absence de détails et d'exemples, il est difficile de juger s'il s'agit d'une erreur de conception ou s'il y a des raisons justifiées...

[Yogy]

Non, ce n'est pas une pratique courante étant donné le nombre d'équipes qui suivent religieusement les recommandations usuelles.

Tout cela pour se retrouver au final avec une couche qui va chercher des données, une couche qui va faire du mapping dans tous les sens pour construire des objets et une couche qui va faire le travail inverse pour afficher ces objets sans qu'aucune valeur n'ai été ajoutée entre la base de données et l'écran...

Tout ça pour dire que la description que tu en fais indique, à priori, qu'il y a effectivement un problème de découpage et d'organisation, mais en l'absence de détails et d'exemples, il est difficile de juger s'il s'agit d'une erreur de conception ou s'il y a des raisons justifiées...

Oui, je recherchais justement ou trouver ces recommandations usuelles. J'en ai lu quelques unes dans les faq ou tutaux sur ce site. Mais y a t-il quelque chose de plus officiel ? Merci !

[Gold Bug]

Oui, je recherchais justement ou trouver ces recommandations usuelles. J'en ai lu quelques unes dans les faq ou tutaux sur ce site. Mais y a t-il quelque chose de plus officiel ? Merci !

C'est pas facile, car justement il n'existe rien d'"Officiel", mais plutôt des recueils de bonnes pratiques, parmi lesquelles:
- Le développement en couches
- L'utilisation de Design Patterns,
- Les outils de validation automatique (genre Microsoft FxCop dont je t'ai parlé dans mon post précédent),
- Utiliser des Frameworks déjà éprouvés plutôt que de réinventer la roue : Log4NET, NHibernate,
- Avoir des tests unitaires qui fonctionnent.

Ce sont tous ces choix de conception techniques qui font qu'entre deux applications qui fonctionnent correctement d'un point de vue utilisateur, la maintenance évolutive (ajout de nouvelles fonctionnalités, changement de SGBD, migration de client lourd vers client léger) sera soit légère, soit un cauchemar.

Le problème, c'est que ces bonnes pratiques, il vaut mieux les prévoir dès le début du projet...

[The_badger_man]

T'as un peu de lecture ici, si tu as le temps: http://msdn.microsoft.com/fr-fr/library/dd144030.aspx

[Philippe Vialatte]

tu peux aussi gagner pas mal de temps en passant un coup de NDepend dessus...

En regardant les metriques de couplage, de cohesion et de complexite cyclomatique.

Tu pourras aussi voir le nombre de ligne de code par methode, et le pourcentage de commentaire...

Assez souvent, tu vois assez bien les points ou tu vas avoir des difficultés
Genre, si la cohesion est faible, si tu as des references circulaires, un couplage efferent fort, et de tres longues methodes, la maintenance va etre de toute facon problematique...ne parlons pas du nombre de lignes de code et de commentaires

Apres, tu as la partie validation du design, ou tu dois travailler au niveau du diagramme de classe, effectivement, regarde les patterns, regarde si ca respecte un tant soit peu SOLID, et DRY

Enfin, si il y'a des tests unitaires/d'integration, une petite passe sur la qualité et la couverture de ces tests vaut le coup

par une société de services

des noms, des noms (et si c'est chez moi, je vais botter des fesses )

[Yogy]

tu peux aussi gagner pas mal de temps en passant un coup de NDepend dessus...

En regardant les metriques de couplage, de cohesion et de complexite cyclomatique.

Tu pourras aussi voir le nombre de ligne de code par methode, et le pourcentage de commentaire...

Assez souvent, tu vois assez bien les points ou tu vas avoir des difficultés
Genre, si la cohesion est faible, si tu as des references circulaires, un couplage efferent fort, et de tres longues methodes, la maintenance va etre de toute facon problematique...ne parlons pas du nombre de lignes de code et de commentaires

Apres, tu as la partie validation du design, ou tu dois travailler au niveau du diagramme de classe, effectivement, regarde les patterns, regarde si ca respecte un tant soit peu SOLID, et DRY

Enfin, si il y'a des tests unitaires/d'integration, une petite passe sur la qualité et la couverture de ces tests vaut le coup


des noms, des noms (et si c'est chez moi, je vais botter des fesses )

Merci pour tout vos renseignements à tous, c'est super, je vais pouvoir argumenter devant mon chef avec des 'vrais' argument.

T'inquietes pas pivalette t'as pas l'air d'être de la région concernée

[Yogy]

J'ai passé un coup de FxCop et de NDepend, ça me rend un report long comme le bras .
PAr exemple dans NDepend au niveau "Assemblies Abstractness vs. Instability" tous les projets sont en bas à droite du graphique dans la zone bleue. Ca veut dire quoi ?
Et FxCop me sort plus de 4000 messages , vous en faites quoi ?

[Philippe Vialatte]

En bas a droite, cela veut dire que tu as plein d'assemblages qui sont tres concrets, mais que peu de classes en dependent...

cela veut dire que tes assemblages *peuvent* être difficile a modifier, mais que comme elles sont peu référencées, les modifs auront peu d'impact

Dans l'absolu, ca ressemble a une appli ou tu as, pour chaque table, une classe d'acces aux donnees, une classe metier, et une dependance a sens unique entre metier et data, sans dependances transverses avec d'autres classes...

C'est pas tres sexy, mais ca marche, surtout si le modele de base de donnees derriere est pas trop complique

Après, cote FxCop, il faut voir les messages en question...

T'inquietes pas pvialatte t'as pas l'air d'être de la région concernée

Moi, non....mais ma boite, si

[Yogy]

J'ai mis en pièce jointe une très petite partie de fxcop, mais représentative je pense des erreurs trouvée. Après j'ai plus de mal à utiliser ce logiciel que Ndepend...

[Yogy]

En bas a droite, cela veut dire que tu as plein d'assemblages qui sont tres concrets, mais que peu de classes en dependent...

cela veut dire que tes assemblages *peuvent* être difficile a modifier, mais que comme elles sont peu référencées, les modifs auront peu d'impact

Dans l'absolu, ca ressemble a une appli ou tu as, pour chaque table, une classe d'acces aux donnees, une classe metier, et une dependance a sens unique entre metier et data, sans dependances transverses avec d'autres classes...

C'est pas tres sexy, mais ca marche, surtout si le modele de base de donnees derriere est pas trop complique

Après, cote FxCop, il faut voir les messages en question...


Moi, non....mais ma boite, si

Question : une dépendance transverse avec d'autres classes, ça se matérialise comment ?