Comment configurer correctement une application MVC comme CakePHP et Laravel?

Question

J'essaie de comprendre les avantages des modèles de graisse et de la notion de contrôleurs maigres. J'ai lu beaucoup d'articles jusqu'ici et ci-dessous sont mes questions. Veuillez répondre aux questions en considérant quelle est la meilleure approche dans CakePHP 3 et laravel 5.2. 1) Est-ce que le fait de suivre les modèles gros/garder la logique métier dans la notion de contrôleurs signifie simplement ne jamais utiliser les méthodes ORM comme find, save, etc à l'intérieur des contrôleurs.

2) Pourquoi tous les exemples dans la documentation de cakephp et de laravel montrent-ils seulement des requêtes à l'intérieur des contrôleurs et non à l'intérieur des fonctions de modèle personnalisées qui devraient être appelées dans les contrôleurs.

3) Il existe de nombreux modèles et architectures comme le datamapper, le référentiel, l'enregistrement actif. Lequel est le mieux adapté aux applications d'entreprise à grande échelle. Est-il préférable d'aller avec Doctrine dans ce cas plutôt que dans les ORM groupés?

4) Et si j'ai besoin d'appeler un autre modèle dans une fonction de modèle personnalisé. Est-ce OK? sinon, quelle devrait être la meilleure approche dans un tel cas. S'il vous plaît expliquer avec un exemple comme cakephp doc utilise blog, utilisateur, commentaires, etc

Merci.

Answer 1

Vous posez des questions assez générales ici alors attendez-vous à des réponses générales. Pour vous donner un aperçu de mes expériences:

1. Non, il existe de nombreux cas où la logique est assez simple ou pas directement liée aux données que la logique métier peut être contenue dans une méthode de contrôleur. Cela étant dit, j'aime traiter les contrôleurs comme la route entre deux points d'extrémité; c'est-à-dire que je peux ramasser des données le long du chemin, mais j'essaie de ne pas manipuler les données dans un contrôleur, simplement le servir à une vue ou à un référentiel à mettre à jour.
2. Simplicité? Il est préférable de ne pas introduire trop de concepts dans un seul exemple. Le même principe s'applique à la programmation, à l'abstraction et à la simplicité.
3. J'ai utilisé le modèle de référentiel, l'enregistrement actif et la doctrine dans tous les projets. C'est le bon outil pour le bon travail.
4. J'essaie de garder l'accès direct au modèle aussi abstrait que possible. Votre schéma de stockage sous-jacent peut changer à tout moment et il vaut mieux ne pas compter sur une sorte de «structure» qui s'y trouve.