2010-01-14 4 views
3

J'ai vu beaucoup d'articles sur l'intégration de ZF et de Doctrine. Il y a aussi une proposition pour ZF here mais ils ont toujours deux structures possibles. Soit ils placent tous les modèles dans un répertoire de modèles de premier niveau, soit ils le placent dans un répertoire de modèles liés au module.Utilisation de Zend Framework et de Doctrine avec des structures modulaires indépendantes

 
application 
|-- Bootstrap.php 
|-- configs 
|-- controllers 
|-- models   - EITHER HERE 
|-- modules 
| -- examplemodule 
|  |-- controllers 
|  |-- models - OR HERE 
|  |-- views 
|-- views 

Pour nos projets, je vois des problèmes pour l'une des deux options:
1. Un répertoire: l'application/modèles - dans un système complexe après un court laps de temps, il y aura des centaines de fichiers, sur tout lorsque vous avez deux classes de table (par exemple User.php et UserTable.php).
2. Répertoires de modèles basés sur des modules: application/modules/examplemodule/models - dans de nombreux cas, nous utilisons des modèles dans plusieurs modules en même temps. Ainsi, "l'utilisateur" est requis par ex. dans les modules "jeu", "administration", ...

Y at-il un moyen d'utiliser une sorte de sous-répertoires sous le répertoire de premier niveau "modèles" pour obtenir un certain regroupement. Il devrait être complètement indépendant de la structure du module. Toute solution doit prendre en charge le chargement automatique et la génération de classe à partir des fichiers yaml.

Des idées, des liens ou des solutions? Merci!

Répondre

1

Nous travaillons actuellement sur une solution à ce problème dans l'entreprise où je travaille.

Nous suivons la structure de répertoire modulaire Zend actuellement, et nous avons notre dossier modèles dans chaque répertoire du module, avec un répertoire de base comme celui-ci:

|----application 
|--------modules 
|------------content 
|----------------models 
|--------------------Base 
|------------------------Content.php 
|--------------------Content.php 

Nos modèles autoload, mais nous n'avons pas intégré la génération de code dans le zi cli, donc nous générons actuellement les modèles, puis les copier dans le répertoire du module manuellement.

Désolé, je n'ai pas la réponse exacte dont vous avez besoin, mais vous pouvez également être intéressé par ce proposal dans la communauté Zend.

+0

Merci Travis, le problème ici est que, avec cela, il est impensable d'utiliser un modèle dans le module A à partir du module B et c'est souvent le cas pour nous. Afin de ne pas inventer une solution complètement non-ZF, nous nous en tenons à la solution «un dossier de modèle au plus haut niveau» et vivons avec de nombreux fichiers dans un dossier ... – stefax

0

Je garde le mien dans un répertoire. Comme le dit le dicton, le temps de développement est cher, et le temps de processeur est bon marché, alors optimisez pour le développeur. Aussi, KISS, et YAGNI. Ne pas optimiser jusqu'à ce que vous ayez besoin d'optimiser. Jusque-là, faites confiance au chargeur automatique.

Pour ce que ça vaut, le site que j'utilise est assez occupé et la performance n'a jamais été un problème.

+0

Oui, c'est comme ça que nous avons décidé de le faire. Le répertoire modèle de notre système contient maintenant beaucoup de fichiers (environ 200 ou plus), donc naviguer et rechercher des modèles spécifiques dans l'EDI est parfois ennuyeux, mais d'un autre côté, personne ne doit penser au sous-répertoire à utiliser pour un certain modèle (parce que parfois plusieurs sous-répertoires seraient appropriés) ... – stefax

0

Le modèle utilisateur n'appartiendrait-il pas au module utilisateur? Et le module de jeu ne devrait-il pas avoir une sorte d'interface pour se connecter à un modèle utilisateur? Comme ne pas utiliser directement le modèle utilisateur dans le module de jeu, mais plutôt passer un adaptateur utilisateur au module de jeu par configuration?

Pour moi, après tout, les modules ont moins de sens lorsqu'ils ne sont pas interchangeables.

+1

Oui, je suis d'accord. C'est la solution la plus propre et vous devriez le faire comme ça, surtout quand vous commencez. À l'époque, lorsque le problème venait d'en haut, j'ai migré un ancien système et nous n'avions pas les ressources pour l'implémenter de cette manière avec des modules interchangeables indépendants mais conservés à proximité des anciennes structures. – stefax

Questions connexes