Création d'un modèle de référentiel

Question

Je suis en train de refactoriser mon code qui consiste en des contrôleurs, en un design de référentiel.

Je trouve la partie la plus difficile en pensant à la responsabilité d'un domaine/fonctionnalité spécifique. J'ai une ExchangeController qui a une méthode trade. Dans cette méthode, il est possible de changer un Shift avec un autre décalage.

Donc je pensais avoir un ExchangeRepository avec la méthode du commerce, mais alors je dois récupérer un Shift.

N'est-ce pas une mauvaise pratique de récupérer un Shift directement à partir du modèle (Shift::find($id)), mais de l'encapsuler en appelant $shiftRepository->get($shiftId)?

Je commence à l'apprendre, mais parfois, il est vraiment difficile de comprendre certaines choses. Est-ce une bonne pratique d'essayer d'encapsuler la plupart des choses à la sienne, au lieu de simplement aller chercher le modèle?

J'espère que c'est un peu clair, lol ..

Answer 1

L'idée principale du dépôt est de cacher les manipulations de base de données d'un autre code. Vous n'êtes pas obligé d'avoir un référentiel par modèle ou par table. Cela conduira à une conséquence très désagréable: l'impossibilité d'exécuter des requêtes complexes sur la base de données. Vous devrez les diviser en petits plus simples chacun contre sa propre table.

est-il pas une mauvaise pratique pour récupérer un décalage directement à partir du modèle (Shift :: find ($ id)), mais pour résumer en appelant $ shiftRepository-> get (shiftId $)?

Je n'aime pas vraiment appeler quelque chose «mauvaise pratique». Tout dépend.

L'appel de méthodes de collecte de modèle directement dans le contrôleur peut sembler plus simple et plus rapide à écrire, mais à mesure que la complexité de votre application augmente, vous commencerez à avoir des problèmes. Par exemple, essayez d'ajouter la mise en cache à votre application avec Model::queryMethod() -comme des appels similaires à travers votre code. Donc, en résumé, je vous recommande de partager vos requêtes dans des dépôts. Choisissez judicieusement les dépôts. Ne faites pas attention à vos noms de table, mais à la logique de domaine de votre application.