Kevin Hooke se demande si le découpage d’une application en plusieurs couches est systèmatiquement intéressant. Son article a sucité une réelle discussion sur TTS.

Introduction

Cette interrogation est surevenue lorsqu’il a commencé à développer en PHP. Habitué aux applications J2EE découpées en plusieurs couches, il a essayé de se documenter sur le découpage multi-couches dans le monde PHP. Et à sa grande surprise, ce concept n’est pas traité par les livres sur le PHP. Il semblerai même que les développeurs soient encouragés à accéder aux données à partir de leurs pages de présentations !

Suite à cet état de l’art, il a constaté que la majeur partie du temps était perdue dans le travail de plomberie pour relier les couches lors du développement d’une application où les aspects sont séparés.

Un faux débat

Pour mettre fin à un débat qui ne devrait pas avoir lieu, Le Java et le PHP ne sont que des languages. Ainsi les modèles de conception ou d’architecture sont valables pour les deux langages.

Alors pourquoi cette différence ? Je pense qu’elle vient du public des deux langages. Je ne suis pas un évangeliste PHP, mais historiquement le PHP est utilisé par des développeurs mais aussi par des apprentis développeurs. Non pas que je veuille dénigrer le langage PHP dans ses lignes, mais n’oublions pas la signification de son sigle : Personal Home Page. Du coup, ce public cherche plutôt a parvenir a leur but rapidement quitte à faire des copier/coller un peu partout. De l’autre côté, le monde Java est poussé par Sun et par des communautés des développeurs à se concentrer sur la conception quitte à parfois oublier l’objectif final : répondre aux besoins de l’utilisateur.

Du code superflu

Après avoir précisé ce point, revenons au premier sujet de l’article : la conception multi-couches. Beaucoup de développeurs reprochent à ce modèle de conception la génération de code superflu pour accéder aux couches. Mais ont-ils oublié que le modèle mono-couche contient énormément de code redondant (accès aux données, règles métier). Et même s’il existe quelques champions du copier/coller et autre rechercher/remplacer, ces techniques ne fonctionnent pas toujours du premier coup.

La maintenance

Selon certaines personnes, la maintenance aisée soit disant acquise grâce au modèle multi-couches n’est qu’une illussion. Ces détracteurs mettent en avant le pire des cas où une opération de maintenance nécessite la modification à la fois de la page de présentation, d’une ou plusieurs règles métiers et de l’accès aux données alors qu’avec une seule couche il ne suffit que de modifier une simple page où tout le code est accessible. Je pense que ces personnes n’ont pas eu à maintenir ces deux types d’applications. Car la simple page où tout le code est accessible se transforme vite en toutes les pages où l’on peut trouver ce genre de code. Ce genre de manipulation ne garantit pas que tout le code a bien été mis à jour (un oubli est si vite arrivé). Alors que lorsque la couche d’accès aux données est modifiée, on peut être sûr que toute l’application gère bien cette nouvelle fonctionnalité. Et celà est vrai également pour une règle métier.

Tout dépend de la taille du projet ?

Sur de très gros projets, tout le monde s’accorde à dire qu’il est préférable de réaliser un découpage en couches (encore faut-il statuer sur le nombre de couches). Avec des projets de moyenne envergure, les avis sont partagés. Pourtant je suis convaincu qu’il est toujours avantageux de découper en plusieurs couches son application. Mais qu’en est-il pour de petites applications (ou de micro-applications) ?

A première vue, le découpage en couches est inutile pour une micro-application. Il fait perdre plus de temps qu’autre chose. Pourtant le jour il sera nécessaire de modifier l’application ou bien d’ajouter de nouvelles fonctionnalités, la question se posera encore. Jusqu’au jour où l’application aura atteint la taille d’un projet de moyenne envergure. Ce jour venu, ce sera l’heure des regrets… Alors regrets ou remords ?