Discussion :

[Aurazed]

Bonjour à tous,
j'ai suivi et mis en oeuvre le tutoriel de Thomas LeBrun sur le developpement en couches: Introduction au développement en couches

Dans ce tutoriel tres bien fait, il n'est pas abordé les différences de performances entre une application développée en couches et une application ne respectant pas ce schéma de developpement.

Je souhaiterais connaitre vos points de vue sur cette question:

Le developpement en couches pénalise t-il les performances de l'application?

[Baptiste Wicht]

Ca dépend par rapport à quoi. Si tu compares par rapport à une application mal developpé et sans architecture en couches, je pense qu'une bonne architecture en couches peut même amélioré un peu les performances. Mais je pense qu'avec une appli bien developpé mais sans séparation des couches, tu as un risque de pertes de performances, mais je pense que c'est minime. Par contre, c'est au niveau de la maintenance que tu vas gagner du temps sur la deuxième application.

J'ai jamais fait de tests, donc je suis pas sûr de ce que je dis.

[souviron34]

Ca dépend par rapport à quoi. Si tu compares par rapport à une application mal developpé et sans architecture en couches, je pense qu'une bonne architecture en couches peut même amélioré un peu les performances. Mais je pense qu'avec une appli bien developpé mais sans séparation des couches, tu as un risque de pertes de performances, mais je pense que c'est minime. Par contre, c'est au niveau de la maintenance que tu vas gagner du temps sur la deuxième application.

J'ai jamais fait de tests, donc je suis pas sûr de ce que je dis.

mwé tu fais bien de rajouter la dernière phrase

En fait, au contraire, une bonne application en couche facilite la maintenance à un facteur exponentiel au nombre de couches.

Regardons bêtement le Web :

Si on fait une application qui mélange au même niveau :

• encodage du protocole tcp
• gestion des sockets
• encodage du protocole html
• affichage

ça fait un joyeux casse-tête


avec en plus l'inconvénient majeur d'avoir à re-développer des parties déjà ultra-utilisées, débuggées, etc...

Il y a d'autres formes de développement, mais le "développement en couches" n'est pas autre chose que la formalisation objet pour le développement et non pour le langage..

"Scope" précis et réduit, indépendance vis-à vis des couches supérieures, réutilisabilité, etc...

Donc certainement pas un désavantage en terme de maintenance....

Quant aux performances, je ne sais pas comment on peut comparer, s'agissant du développement... Un binaire est un binaire.. Qu'on l'ai développé en couches ou non. Dès qu'on fait appel à une routine, il y a un peu d'overhead. Mais il est le même dans les 2 cas.

[Baptiste Wicht]

mwé tu fais bien de rajouter la dernière phrase

En fait, au contraire, une bonne application en couche facilite la maintenance à un facteur exponentiel au nombre de couches.

Regardons bêtement le Web :

Si on fait une application qui mélange au même niveau :

• encodage du protocole tcp
• gestion des sockets
• encodage du protocole html
• affichage

ça fait un joyeux casse-tête


avec en plus l'inconvénient majeur d'avoir à re-développer des parties déjà ultra-utilisées, débuggées, etc...

Il y a d'autres formes de développement, mais le "développement en couches" n'est pas autre chose que la formalisation objet pour le développement et non pour le langage..

"Scope" précis et réduit, indépendance vis-à vis des couches supérieures, réutilisabilité, etc...

Donc certainement pas un désavantage en terme de maintenance....

Quant aux performances, je ne sais pas comment on peut comparer, s'agissant du développement...

C'est bien ce que j'ai dis

Je disais bien que c'est un gain de temps en terme de maintenance avec une architecture en couches. Je suis tout à fait d'accord avec toi. Mais je m'exprime peut-être mal.

Ma dernière phrase était pour les performances.

[souviron34]

Ok alors j'avais mal compris cette phrase :

...
Par contre, c'est au niveau de la maintenance que tu vas gagner du temps sur la deuxième application.
...

Désolé

[Aurazed]

Si je vous suit bien,
à qualité de codage égale, l'architecture en couche n'influence pas les performances de l'application?

[souviron34]

Absolument..

Les perfomances "runtime" n'ont absolument rien à voir avec le modèle de développement....

Par contre, cela a à voir avec la qualité du codage.... Et l'optimisation du code.. Et l'usage ou non d'un langage compilé. et la vitesse du CPU, et la vitesse des bus, et la taille mémoire, et la taille du swap, et le "gérant" des processus, etc.....

[Aurazed]

Merci pour toutes ses précisions.

[Hafiz.B]

Moi j'ai une autre question peut etre bete mais je la pose quand meme (lol).

Est ce qu'on peut utiliser la classe de la couche BLL de la meme facon dans une aplli web que dans une appli Window? Je veux dire par la, est ce que le fait d'utiliser un singleton et de locker l'instance ne va pas poser des problemes quand on a plusieur utilisateurs qui font appelle au meme objet, et peut etre en meme temps!

Merci pour les reponses.

[chimane9]

Bonjour Aurazed

j'ai vu que vous avez mis en oeuvre le tutoriel de Thomas LeBrun sur le developpement en couches, moi aussi je viens de le faire puisque j'ai à developper une application avec .Net et Sql server et j'ai choisi de le faire avec la technique N-tier, le problème c'est que a la compilation j'ai les deux erreurs suivantes:

'System.Windows.Forms.ListBox' does not contain a definition for 'DataContext'

'System.Windows.Forms.ListBox' does not contain a definition for 'DisplayMemberPath'

Est ce que cela pourrait etre du au fait que j'utilise du WindowsForms alors que le tutoriel utilise WPF?

Merci d'avance pour votre aide

[wiztricks]

Si je vous suit bien,
à qualité de codage égale, l'architecture en couche n'influence pas les performances de l'application?

Si on écrit une application objet en Java, on va l'exécuter sur une couche logicielle qui s'appelle la JVM.
Si vous développez en C++, vous n'aurez pas cette couche d'abstraction et les performances seront généralement meilleures.

=> Chaque fois qu'on ajoute des couches, le risque d'impact sur les performances ne sera jamais nul.

Ceci dit en échange de ce risque (et souvent de ce prix), vous obtiendrez:

1. des modules ré-utilisables, plus robustes, plus simples à maintenir,
2. moins de code à écrire pour livrer votre application,
3. ...

Faut-il partiellement violer la belle architecture en couche pour obtenir de meilleures performances?
Parfois cela vaut le coût: ne ré-écrit-on pas certains algo en assembleur?
Mais il va falloir arbitrer ce bénéfice avec les soucis que cela va poser en maintenabilité,...
- W

[Eugene]

Cet article est très bien écrit mais il y a tout de même deux points sur les quels j'aimerais apporter des précisions :

Permier point : L'utilisation du pattern Singleton.
Le pattern Singleton n'est pas la panacée pour gérer les connexions. C'est vrai qu'il permet de n'avoir qu'une seule instance de la connexion à la base de données, mais cela n'est rentable (et viable) que dans un contexte non web. Dans un contexte web, le pooling de connexion des SGBD va être dérouté par la réutilisation d'une seule instance de connexion (erreur du genre connexion already opened, ou connection has been closed...). Il vaut mieux, dans un contexte Web utiliser une connexion éphémère.

Second point : Le respect de l'intimité des couches. Thomas n'appuie pas assez sur le fait qu'une seule fuite d'intimité peut effacer tous les avantages de cette architecture. Il est IMPERATIF de respecter la séparation des couches et ce modèle de développement nécessite une grande rigueur et également l'adhésion de l'ensemble de l'équipe sur le long terme.

Voilà, c'est tout

Eugene