Estructura óptima del sistema de archivos para el lenguaje de script Aplicaciones MVC

Question

Cuando hablo de lenguajes de scripting estoy hablando de lenguajes como Python, Perl y (en mi caso) PHP. Después de usar CodeIgniter, Zend y muchos otros sistemas divertidos de MVC, parece claro que una cosa en la que uno parece estar de acuerdo es en la estructura de la carpeta (junto con otras cosas_como_que). Esto realmente me está causando un problema porque no puedo encontrar ninguna buena documentación sobre los beneficios de diferentes diseños de estructuras. La mayoría de las personas simplemente recomiendan uno porque es lo que usan sin tener en cuenta las mejoras en el diseño.

Una de las cosas en las que espero que todos podamos estar de acuerdo es que comprobar el sistema de archivos en busca de archivos existentes cuando se cargan automáticamente las clases es una práctica muy mala. Nuestras clases no deberían estar en una de las 5 ubicaciones posibles que causan una avalancha de verificaciones file_exists() para cada biblioteca que cargamos.

Así que de todos modos, estoy tratando de recopilar las estructuras de directorio que puedo comparar para encontrar las mejores prácticas en la planificación de las aplicaciones que:

1. Se basan programación orientada a objetos que muy probablemente significa MVC
2. de alcance internacional y los archivos/traducciones
3. están abiertos a los módulos de idiomas de apoyo/plugins de manera que los paquetes completos pueden ser dejados en nuestra base de código
4. definir claramente lo que está pasando y dónde buscar para las clases dadas
5. Posible apoyo para múltiples sitios que se ejecutan fuera de la misma estructura (ver directorios y/o Zona de abajo)

Así que aquí es lo que tengo hasta ahora. Tenga en cuenta que libs es solo un término que significa su directorio principal de biblioteca/clase e incluso puede contener modelos según la estructura de la carpeta. Además, excluí cualquier tipo de contenido estático (JS/CSS/images) ya que ese material es realmente una idea posterior y no está relacionado con nuestro código del servidor, ¡incluso puede estar en otro servidor! Lo mismo ocurre con las memorias caché, las cargas de archivos, lang y todo el resto del contenido generado.

/controllers 
/views 
/models 
/libs 
/config 
index.php 

Este tipo de me recuerda el Zend Framework, que amontona todo en una carpeta libs sola (que también incluye las subcarpetas para mantener las cosas organizadas). Solo funciona para un solo sitio.

---

/libs 
/site 
    /controllers 
    /views 
    /models 
    /config 
index.php 

Esto haría una versión multi-sitio de la estructura anterior.

---

/libs 
/functions 
/site 
    /controllers 
    /models 
    /views 
    /config 
/site2 
    /controllers 
    /models 
    /views 
    /config 
/modules 
    /user 
     /controllers 
     /models 
     /views 
index.php 

Esta sería la versión que permitiría a múltiples sitios y caída de los módulos. Los módulos serían aplicaciones MVC independientes como un foro que incluiría lógica de negocios, CRUD y vistas.

¿Alguien tiene una estructura perfecta que podrían compartir o guiarme en la elección de un buen diseño ampliable?

Answer 1

Aquí hay un ejemplo demasiado complejo que hace un buen trabajo organizando todo, a costa de la claridad y la simplicidad.

alt text http://www.gsdesign.ro/blog/wp-content/uploads/2008/12/zend-framework-modular-dire.png

Answer 2

No

que recomiendan específicamente symfony, sino que es el enfoque, que creo que es pretty good (pero no "perfecta")

permite:

• I18N
• múltiple entornos (dev, qa, prod, etc.)
• Bibliotecas externas
• Plugins
• sitios múltiples (dominios o de otro tipo) (tareas de línea de comandos)
• El procesamiento por lotes
• pruebas unitarias
• Documentación
• registro
• almacenamiento en caché

Además, entre los altibajos de Symfony, una cosa que creo que funciona bastante bien es el almacenamiento en caché. Y no me refiero a template/view caching - Me refiero a compilation-like caching.

Cuando se ejecuta un proyecto por primera vez, Symfony construye un archivo maestro de clases de biblioteca que, tras visitas sucesivas a la aplicación, no solo elimina docenas o incluso cientos de llamadas estadísticas por solicitud, sino que realiza otras optimizaciones como la eliminación de comentarios.

También almacena en caché los datos de configuración y la información de carga automática, todos los cuales se pueden modificar según sus necesidades.

Answer 3

Utilizamos una estructura similar a su última opción "multi-sitio" para un motor de foro de varios sitios que construimos en casa y funciona muy bien. Siempre puede copiar los módulos si lo necesita, y también permite la posibilidad de que el Sitio A personalice su módulo un poco sin afectar el Sitio B.

Cuando se trata de aplicaciones prácticas de esto, está hablando de algo completamente separado equipos, tal vez incluso las empresas que utilizan esos dos sitios, una pequeña división no es lo peor. También tenemos una carpeta de módulos compartidos, pero si asigna un nombre a un archivo en la carpeta de módulos del sitio, en su lugar usa esa versión. Usando eso y __autoload (asumiendo PHP), entonces los desarrolladores del sitio realmente no tienen que preocuparse de dónde se encuentra el módulo para usarlo.