Discussion :

[mactwist69]

Bonjour la communauté,

Cela fait longtemps que je n'étais pas venu, mais j'ai repris le travail depuis...
Je commence donc un nouveau boulo, et j'intègre une équipe qui développe plusieurs programmes en VB.NET, qui suis une architecture en couche.

- Pour faire simple coté utilisateur: il y la couche Interface qui attaque une couche intermédiaire (BP) (qui elle même attaque la couche WCF du serveur).
- Coté serveur: il y a donc puis un serveur (WCF) qui attaque la BL (business layer), puis la couche d'accès au données (DL).

Sauf que, je crois que le responsable du projet ne comprends pas très bien le fonctionnement de la programmation en couche et en classe. En fait, pour chaque fenêtre de l'interface, il créer une classe dans chaque couche, pour ranger les fonctions qui y sont utilisées. (et encore je simplifie).

Bon on pourrait dire pourquoi pas. Sauf que: TOUTES les classes, sont shared, donc au lieu de créer une instance de classe on fait un truc du genre:
BP.MaFonction(). Lorsque l'on fait cela, un système regarde si la classe est instanciée, si elle ne l'est pas elle l’instancie. Toutes les fonctions des classes fonctionnent de manière autonome (en utilisant des paramètres donc), comme ci toutes les couches n'étaient en fait que des modules.

Pire: dans l'interface, on a ajouter une référence à la couche BL, et comme les classes (elle n'est une classe que par son nom) sont shared, du coup ils appellent parfois directement la couche BL depuis l'interface.

Alors, il y a bien sur plein de problèmes de logique, d'organisation, de compréhension etc....
Mais en plus de cela, je trouve le logiciel particulièrement lent.
Et j'ai essayé de debuger un bout de programme... Et le debugage par dans tout les sens, passant d'une fonction a une autre et ainsi de suite, comme si ca avait créer un multithread de fou qui ne sait plus ou donner de la tête.

Ma question est donc la suivante: est ce que vous pensez qu'avec cette utilisation des couches et des classes shared, les appelles sont ils asynchrones, ce qui expliquerait le debugage ne cesse de changer de couche et de classe.

J'essai de trouver des arguments pour pouvoir le moment venu, expliquer pourquoi faire des modifications dans l'architecture et la méthode... Donc vous pouvez vous lâcher !

Merci d'avance

[mactwist69]

Bon alors, je pense m'être trompé sur le fait que les procédures shared fonctionnent en asynchrones.

Enfin, disons que c'est parce qu'on passe par une couche serveur qui fait que quand je debug en local il va dans toutes les couches.

Mais à l'appel d'une fonction d'une couche supérieur, le fonctionnement normal ne devrait il pas être synchrone ?

[DotNetMatt]

Premièrement, Shared n'a rien à voir avec le fait qu'une méthode soit asynchrone ou synchrone. Comme tu l'as écrit dans ton premier post, Shared permet de n'avoir qu'une seule instance de la classe disponible pour toute l'application.

Sans rentrer dans de trop grandes considérations, si toutes les classes sont Shared, on peut dire que l'application est extrêmement mal architecturée. Il faudrait connaître plus en détail l'historique du projet et le projet en lui-même pour savoir pourquoi est-ce que ton équipe en est arrivée là, mais ce qui est sûr, c'est que la personne en charge de l'architecture est complètement à côté de la plaque.

Pour répondre à ta question, il est normal que tu sois baladé de partout en débuggant. De plus, il a sûrement fallu faire face à des problèmes de concurrence, donc vu ce qui a été fait, il ne serait pas étonnant de trouver des rustines assez bizarres dans le code...

[mactwist69]

Oui merci de me confirmer cela (pour l'asynchrone).

Quand à l'architecture, va falloir convaincre... je sens que ça va pas être facile. LE projet est pourtant tout neuf, quel dommage.
Je marque en résolu