Comment démarrer son projet avec une bonne architecture ?

Projet architecture code sqli

Dans le monde du développement, pour tout projet, on passe beaucoup de temps à écrire du code. Notre objectif principal est justement d’écrire du code propre, c’est-à-dire un code facilement maintenable, réutilisable et sans redondance. Je vous donne quelques clés pour atteindre cet objectif, autrement dit pour bien démarrer son projet avec la bonne architecture. 

Séparer les couches 

Nous devons commencer par la séparation des couches. La séparation des couches dans une application permet de faciliter la maintenance du codePrenons comme exemple une application ayant trois couches, c’est-à-dire :  

  • Une couche d’accès aux données (DAL) 
  • Une couche métier (BLL)  
  • Et une couche interface utilisateur (UI) 

Le rôle de la couche d’accès aux données est la sélection et la persistance de données en base de données. La couche métier permet quant à elle d’appliquer les règles métiers et les règles de gestion. Elle ne communique qu’avec la couche d’accès aux données. Le rôle de la couche UI est de représenter les données via l’interface utilisateur. C’est la couche UI qui interroge la couche métier pour avoir l’accès au traitement et à la représentation des données. 

Cette séparation permet d’intervenir indépendamment sur chacune des couches de l’application sans que les autres soient impactées 

 

Résoudre le manque d’étanchéité 

Les différentes couches communiquent via une interface afin de réduire au minimum la dépendance entre elles. La communication via interface ne garantit pas l’étanchéité entre les couches.  

Dans la couche UI, on fera un « new » pour instancier l’objet de la couche métier par exemple. C’est ce « new » qui fait que les couches ne sont pas complètement étanchesEn effet, une modification de la signature du constructeur de la couche métier nous amène à faire la même modification partout où ce constructeur est appelé dans la couche UI. C’est ce qui crée une dépendance entre les couches UI et métier. 

Pour corriger ce problème de dépendance (couplage) entre les couches, a été introduite la notion d’injection de dépendance. Elle permet de ne pas se soucier de l’instanciation d’autres objets/modules dont ces derniers dépendent, et par conséquent de pouvoir les réutiliser dans d’autre classes. 

Pour éviter au mieux les dépendances, deux types d’injection de dépendance sont fréquemment utilisés : l’injection par propriété et l’injection par constructeur.

Injection de dépendances par propriété

La mise en place de l’injection de dépendance par propriété est assez simple. Il suffit d’offrir une propriété publique qui permettra de setter la dépendance que l’on veut injecter.  

L’une des limitations de cette approche est d’appeler une dépendance sans l’initialiser, ce qui va produire une exception de type NullReferenceException.

Injection de dépendances par constructeur

L’injection de dépendance par constructeur est l’approche la plus couramment utilisée dans la mise en place de la pratique. Il s’agit simplement de passer la dépendance comme paramètre du constructeur. Son implémentation est simple et offre l’avantage d’éviter l’utilisation d’une dépendance noninitialisée. 

 

Une fois toutes ces pratiques mises en place, on peut réussir de vastes projets avec un code clair, bien rangé, réutilisable et facile à maintenir. Cela permet également aux nouveaux entrants dans le projet de prendre facilement le train déjà en marche. 

0 commentaires

votre commentaire

Se joindre à la discussion ?
Vous êtes libre de contribuer !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Inscription newsletter

Ne manquez plus nos derniers articles !