MVC + Repository Pattern Flashcards
Expliquez la différence entre le modèle MVC et le Repository Pattern
Le MVC est une architecture globale qui organise l’application en trois couches distinctes (Modèle, Vue, Contrôleur) pour séparer les préoccupations. Le Repository Pattern, quant à lui, est un design pattern spécifique qui ajoute une couche d’abstraction pour l’accès aux données. Il peut être utilisé à l’intérieur du “M” (Modèle) dans l’architecture MVC pour isoler la logique métier des détails d’implémentation de l’accès aux données.
Quels sont les avantages d’utiliser un Repository Pattern dans une architecture MVC ?
- Séparation claire des responsabilités
- Code plus testable (possibilité de mock des repositories)
- Centralisation de la logique d’accès aux données
- Réduction de la duplication de code
- Facilite le changement de source de données ou d’ORM sans impacter la logique métier
- Améliore la maintenabilité et la lisibilité du code
Comment implémenteriez-vous concrètement un Repository dans une application web ?
J’implémenterais d’abord une interface (ou classe abstraite) définissant les méthodes standard comme findAll(), findById(), create(), update(), delete(). Ensuite, je créerais une implémentation concrète de cette interface pour chaque entité de mon application. Chaque repository utiliserait les méthodes d’accès aux données (ORM, requêtes SQL directes, etc.) tout en exposant une API cohérente aux contrôleurs. Les contrôleurs utiliseraient alors ces repositories pour obtenir ou manipuler les données sans connaître les détails d’implémentation.
Quelle est la différence entre un Modèle et un Repository ?
Un Modèle représente la structure des données et peut inclure des règles de validation et de la logique métier spécifique à ces données. Un Repository, quant à lui, est responsable de la persistance et de la récupération des données. Le Modèle définit “quoi” (structure des données), tandis que le Repository définit “comment” (accès et stockage des données).
Comment gérez-vous les transactions dans un Repository Pattern ?
Je gérerais les transactions soit au niveau du Repository, soit via un service dédié à la gestion des transactions. Dans le premier cas, le Repository aurait des méthodes comme beginTransaction(), commitTransaction() et rollbackTransaction(). Dans le second cas, j’utiliserais un service de transaction qui envelopperait les appels aux repositories. Une autre approche consiste à utiliser un middleware ou un aspect pour gérer automatiquement les transactions.
Quelles sont les limites du Repository Pattern et comment les surmonter ?
Les limites incluent :
- Surcharge potentielle pour les petites applications
- Duplication possible de code entre repositories similaires
- Complexité accrue pour les requêtes très spécifiques
Pour surmonter ces limites, je pourrais :
- Utiliser des repositories génériques pour réduire la duplication
- Implémenter un système de spécifications pour les requêtes complexes
- Utiliser des services supplémentaires pour la logique métier complexe impliquant plusieurs repositories
Comment testeriez-vous un contrôleur qui utilise un Repository ?
Je créerais un mock du Repository en utilisant un framework de mocking (comme Jest, Mocha, PHPUnit selon le langage). Ce mock simulerait les méthodes du Repository avec des données prédéfinies. Je pourrais ainsi tester le contrôleur de manière isolée, en vérifiant qu’il appelle correctement les méthodes du Repository et qu’il traite correctement les données retournées, sans dépendre d’une véritable base de données.
