Pour le développement de nos services, qui seront des composants de cette architecture :
Une bonne pratique consistera à implémenter le pattern Repository. Notre application se décomposera en 3 couches :
- Une couche Service qui expose les points d’entrée. Elle peux être également responsable de la gestion des exceptions, de l’authentification et des logs.
- Une couche Business qui contient la logique fonctionnelle. Elle organise les context de connexion à la base (UnitOfWork) et appelle les repository pour effectuer des opérations sur la source de données.
- Une couche Repository qui accède ou modifie les données.
Schéma d’architecture d’un service. Les flèches en rouge représente des appels non autorisés.
Chaque couche est séparée par des interfaces pour la mise en œuvre de l’injection de dépendance dans nos projets.
A noter que Asp .Net Core supporte nativement cette bonne pratique via la classe ServiceCollection.
Au niveau des framework et outils tiers nous pourrons utiliser, en vracs :
- Pour l’accès aux données : l’ORM Entity Framework Core.
- Automapper : pour mapper facilement un objet entités avec un POCO ou DTO pour le transport des informations.
- Swagger pour la présentation de nos API. Une valeur sure !
- Postman pour les tests locaux de communication avec notre API.
- Nuget qu’on ne présente plus pour le partage des interfaces et des objets.
- Nunit + Un Framework de mocking tel que Moq ou Rhino Mock pour les tests unitaires.
J’en oublie surement mais j’ai cité les indispensables 🙂
A très vite pour la partie dev !