Mes principales réalisations incluent :
◽ Les couches d'architecture: Entités métiers, DTO, DAO, BLL, une API REST, et une interface client en MVC.
◽ La sécurité : Mise en œuvre de l'authentification via Negotiate et d'autorisations basées sur les groupes Active Directory.
◽ La base de données : Conception et gestion d'une base relationnelle à l'aide d'un projet SQL dans Visual Studio.
◽ Le déploiement : Mise en place d'un pipeline CI/CD avec Azure DevOps pour automatiser les tests, la construction, et le déploiement de l'application.
Pour illustré l'ensemble de ces couches, je vais utiliser l'entité Application du DataWiper.
Cette couche contient les concepts fondamentaux du domaine métier et leurs règles. Ces entités représentent des objets réels ou abstraits liés à notre domaine (par exemple, un filtre). Elles encapsulent les propriétés (attributs) et comportements (méthodes métier).
Cette couche est directement liée à la structure de la base de données. Les objets dans cette couche reflètent les tables, les relations, et les colonnes de notre système de stockage.
Cette couche agit comme un intermédiaire entre notre service métier et la base de données. Elle abstrait les détails de l'accès aux données (CRUD) via des repositories ou des connecteurs.
C'est le chef d'orchestre de notre logique métier. Cette couche contient des cas d'utilisation spécifiques qui combinent plusieurs entités et données. Elle utilise les entités métier et les adaptateurs pour effectuer des opérations complexes en proposant une série de méthodes qui seront utilisables pour le client.
La couche qui sert de point d'entrée pour les clients externes. Elle expose les fonctionnalités de notre application sous forme d'API web (REST), reçoit les requêtes HTTP et communique avec la couche métier (BLL).
La partie interface utilisateur de notre application. Elle inclut la logique de contrôle et les éléments visuels permettant aux utilisateurs d'interagir avec le système.
La sécurité de DataWiper repose sur deux axes: authentification et autorisation, essentiels pour contrôler l'identité et les droits d'accès.
â—˝ Utilisation du schema Negotiate qui permet de s'authentifier via les sessions de Windows (avec popup login/mdp).
â—˝ VĂ©rification dans le cache session des habilitations existantes.
◽ Mise à jour en récupérant les groupes AD si les informations ne sont pas disponibles ou obsolètes.
◽ Validation des droits d'accès (CRUD, applicatif, environnement).
La base de données SQLServer pour DataWiper est conçue à partir d'un Modèle Conceptuel de Données (MCD), puis transformée en un Projet SQL Server dans Visual Studio.
◽ Création d'un nouveau projet de type « Projet de base de données SQL Server » dans Visual Studio.
◽ Les tables peuvent ensuite être créées facilement à l'aide d'un "Designer" visuel ou par l'écriture de scripts.
Le projet DataWiper est versionné sur Azure DevOps, qui gère la CI/CD (intégration continue/déploiement continu).
En images:
1 -
2 -
3
◽ Application et base de données sont maintenues dans le repo Azure DevOps, avec plusieurs pipelines disponibles (Master, Dev, SQL, etc.).
Lorsqu'un pipeline est exécuté (via Run Pipeline), Azure DevOps :
â—˝ Compile et archive l'application.
◽ Déploie automatiquement les fichiers nécessaires sur l'environnement cible.
◽ Met à jour la base de données (scripts SQL déployés via le pipeline SQL).