¿Estructuras de organización de aplicaciones PHP inteligentes?

10

Hay un millón y uno de estructuras de sistemas de archivos que se incluyen en la miríada de proyectos de código abierto disponibles. Cosas como módulos, archivos de idioma, dominios, bibliotecas de terceros, migraciones, internacionalización, copias de seguridad y enlaces de sistema a otras partes del sistema han dado lugar a muchos enfoques para organizar el sistema de archivos de un proyecto.

Como desarrollador de PHP, me pregunto si algún tipo de estandarización está comenzando a surgir entre los proyectos. Con PSR-0 finalmente tenemos un estándar para nombrar y cargar archivos, pero no sé nada sobre el resto de los componentes que componen el sistema o cómo se pueden manejar de una manera sensata.

Estamos tratando con mucho más que solo MVC, entonces, ¿qué ejemplos hay de proyectos grandes que manejen correctamente todas estas cosas?

php  project-management  code-organization  file-structure 
— Xeoncross
fuente
3
Como compañero desarrollador de PHP, no esperaría cordura de los componentes de PHP
— CamelBlues
2
@CamelBlues Basado en las probabilidades de azar, algunos desarrolladores de PHP finalmente tienen que equivocarse y hacer algo bien.
— Xeoncross
No he visto mucho en cuanto a la estandarización. Hasta los últimos años tendrías tus carpetas para cosas de front-end (js, css) y luego tendrías inclusiones o libs y luego plantillas o temas y eso fue todo. Recientemente, con los marcos MVC ganando popularidad, todo esto no está claro. Yo diría que no se preocupe por usar un estándar por ahora y simplemente deje en claro qué sucede en cada aplicación en particular.
— Jason

Respuestas:

3

Realmente no es posible estandarizar cómo deben presentarse los proyectos, porque "depende".

Si introduce una estructura estándar, pero parte de ella no es relevante para los requisitos que se están desarrollando, puede terminar con un ruido adicional que no necesita. Del mismo modo, si los estándares deben funcionar para una amplia gama de proyectos, deberán incorporar demasiados escenarios dispares.

Nuestro trabajo como desarrolladores es buscar patrones y mejores prácticas y aplicarlos a la tarea en cuestión. Utilizamos nuestra experiencia y conocimientos para elegir la estructura de sistema de archivos adecuada para el proyecto en el que estamos trabajando.

— Fenton
fuente
+1 En general, estoy de acuerdo con usted, este es ciertamente un punto válido. Sin embargo, si elimina elementos fuera del idioma (carpetas de respaldo, scripts cron / build, activos estáticos, etc.) y solo se enfoca en el lenguaje en sí mismo, no creo que se pueda hacer el mismo argumento. Los idiomas ya tienen limitaciones impuestas. Descubrir cómo organizar todas sus clases y bloques de código para que tengan sentido para cada proyecto es un objetivo real y alcanzable.
— Xeoncross
0

No parece haber mucho esfuerzo de estandarización, y para ser honesto, no veo el beneficio. Solo hay una regla que debe cumplir, que es que nunca debe tener cosas debajo del docroot que no pertenezcan allí (una precaución de seguridad básica).

Aparte de eso, simplemente iría con lo que tiene sentido para el proyecto.

Si está utilizando MVC (ya sea a través de un marco o ad-hoc), entonces tiene sentido una estructura base con / modelos, / vistas y / controladores. Pero incluso si no lo es, generalmente tiene algún tipo de capa de acceso a datos con clases que se asignan a sus entidades de datos; tiene sentido tener un directorio para esos; También suele tener un montón de clases de lógica de negocios y funciones de utilidad, por lo que otro directorio para ellos; si usa un sistema de plantillas, las plantillas van a otro directorio; y luego probablemente desee un directorio de 'bibliotecas', donde coloque todas las bibliotecas de terceros. (Una vez que hayas llegado a este punto, de todas formas estarás haciendo MVC).

Si el proyecto es realmente grande, probablemente se puede dividir en submódulos funcionales; si los submódulos son bastante independientes, tiene sentido usarlos como su nivel superior, con un directorio adicional para el código común.

— tdammers
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.