Zend FR

Non c'est une classe que Zend ne propose pas.

Elle n'érite pas de ZCA car ZCA est faite pour faire un contrôleur or Un controleur n'est pas un modèle.

imagine que tu veuillepublier les fonctionnalité de ton modèle en SOAP tu fait une classe modèle qui définit les méthodes en question et tu l'expose avec UN soap serveur

pour que ça fonctionne il suffit que ce soit une classe pas un controleur une classe simple

Le pattern MVC sert à séparer les traitement entre l'affichage et le modèle le controleur assurant la liaison
le patter façade lui sert à masquer une complexité d'implémentation. il fournit un accès Unique à une semble de fonctionnalité.

les deux combiné te permete de mieux séparer les couche.
en gros la façace c'est l'API de ton modèle quand tu lui demande un user il te donne un user et tu n'a pas à savoir si il a fallut utiliser une base une seule classe ou une multitude
tu as une fonction d'accès et le reste n'a pas d'importance.

si je prend ton exemple avec la méthode __get tu ajoute une fonctionnalité au controleur qui te donne accès à une classe métier

passer par la façade ne te donne pas accès à une ou plusieurs classes métier tu as accès à l'ensemble des fonctionnalité du métier.

l'intérêt est que si tu change d'implémentation tu n'as pas à changer tous les contrôleur qui l'utilise seule la façade est redéfinie.

typepiquement Zend_Auth est une façade d'autentification. tu as une méthode pour savoir si oui ou non l'utilisateur est reconnu.
pour la rendre générique tu est obligé de la configurer mais si tu change de configuration tu ne change pas la méthode d'accès

contrairement à Zend_auth le modèle d'une appli lui est propre il n'y a donc aucune raison de la configurer elle doit elle même tout définir.

tu controleur du coup reprends sont seul rôle de chef d'orquestre il ne demande pas les donnée pour faires des truc avec il demande au modèle de faire le nécessaire et ne fait que donner les résultat à la vue.
le travail du controlleur est le suivant
- lire et filter les infos du client
- demander au modèle de les traiter
- donner les donnée résultante à la vue
- gérer les enchainement.

le reste n'est pas de son ressort il n'a pas à savoir comment est fait la vue ni comment travaille le modèle.
pour la vue Zend $this->view mais ne fourni rien pour le modèle.

A+JYT

Je me permet de relancer ce post. Je n'ai pas avancé beaucoup depuis la dernière fois et pour tout dire, je suis un peu en attente d'avis sur la question.

Encore merci d'avance.

Oki. Je rencontre pas mal de problème pour mettre son architecture en place.
Je n'arrive pas à savoir ce qu'il y a de présent dans les classes "Fast_Model_Component" et "Fast_Controller_Action".

Le luxe serait d'avoir l'arborescence, le nom des fichiers et le contenu des fichiers qui sont strictement nécessaire au fonctionnement de la couche modèle.

Dans la doc, tu parles de Fast_Controller_Action et je n'ai pas l'impression que cela sert vraiment à ce que l'on veut apprendre. Il y a pas mal de partie comme ça qui, personnellement mais je ne doit pas être le seul, déroute pas mal.

Dans le post que tu as rajouté, c'est bien de la classe "Fast_Model" que tu parles ou bien plutôt de la classe "Fast_Model_Component" ?

PS : Je ne sais pas si tu as eu mon mail mais ma proposition tient toujours...

Juste pour continuer à être convaincu, quel est l'avantage d'utiliser ta classe pour inclure les différents modèles plutot que de faire directement un

Zend_Loader::loadClass('Modelusers');
Zend_Loader::loadClass('Modelnews');

//etc

dans les controllers qui en ont besoin ?

Oui, je comprends bien, mais si dès le départ, je décide de faire des modèles différents selon les modules de mon application (1 modèle pour mes news, un autre pour mes articles, un autre pour mon forum etc) et que je les charges juste dans les controlleurs qui en ont besoins. Je pense que j'aurai également ce gain de performance non ?