Como muchos han mencionado, debe buscar en los marcos PHP populares porque lo ayudarán a mantener su proyecto más organizado de lo que probablemente se sienta inspirado a hacer por su cuenta.
Una vez que tenga mucha experiencia en la construcción de aplicaciones a mayor escala, estará en una mejor posición para diseñar su propio marco si decide que nada por ahí satisface sus necesidades exactas.
Puede evitar ese consejo y referirse a su propia solución como cualquier cosa menos un “marco”, pero las convenciones que diseñe terminarán siendo exactamente eso. Tendrá un marco de una forma u otra, o su proyecto será imposible de mantener.
Por mi parte, ingenuamente comencé lo que se convirtió en un gran proyecto PHP empresarial sin un marco explícito en 2002. Terminé incorporando Zend Framework como andamiaje, pero sentí que gran parte estaba demasiado hinchado para mis necesidades.
Pasé un año estudiando frameworks como Tapestry / Hibernate en Java Server Pages, Django en Python, Eclipse RCP en Java, Zend Framework en PHP, etc.
En 2008 terminé reescribiendo completamente mi proyecto desde cero y creé mi propio marco subyacente (completamente separado de la aplicación) basado en las necesidades específicas de mi proyecto. En ese momento, sabía exactamente lo que estaba haciendo y por qué lo hacía porque había pasado 6 años trabajando con el código todos los días. Aprendí por haber jodido mucho. Los mejores marcos condensan ese mismo tipo de aprendizaje, y usted se beneficiará de ello incluso si no comprende cuán lejos podría haberse desviado sin orientación.
Ahora son 6 años más tarde y llevo 12 años trabajando en el mismo proyecto PHP. He introducido alrededor de 1,000 mejoras por año a partir de los comentarios de la comunidad. Si bien eso suena como una pesadilla de arrastre de características, la mayoría de esos cambios en realidad limpian características dispares y redundantes y reducen la base de código. Refactorizo religiosamente, y el proyecto está más organizado hoy que nunca.
No podría desarrollarme con esa consistencia y velocidad sin una sólida comprensión de los marcos. Es por eso que me considero más un arquitecto de software que un desarrollador típico.
Volviendo a los detalles específicos de su pregunta, el problema no es tener demasiados archivos de código fuente en el back-end. Generalmente, el sistema operativo los almacenará en la memoria caché y los guardará sin memoria; y también es probable que residan en un caché de código de operación PHP. No importa si tiene 1000 archivos si la mayoría no se utilizan en la misma solicitud. De hecho, he encontrado que es mucho más rápido tener un montón de archivos pequeños que unos cuantos más de 3000 líneas.
Lo que desea evitar es que los usuarios finales tengan acceso directo a demasiados archivos a través de URL. Debe buscar en el patrón de diseño Modelo-Vista-Controlador. En mi aplicación, solo hay dos archivos PHP accesibles para el navegador (index.php y ajax.php). Utilizo rutas virtuales como ‘/ setup’ o ‘/ search’ que se enrutan a un código diferente por el marco de back-end. Eso proporciona mucha más seguridad y organización que permitir el acceso directo a páginas como setup.php o search.php.
Con una buena comprensión de su IDE (Eclipse PDT en mi caso), podrá navegar por esos archivos sin muchos problemas. La mayoría de las veces solo estás abriendo archivos con algunas letras de su nombre. Usted sabe a dónde pertenecen las cosas porque su marco lo ha animado a organizarlas de manera consistente (API, recursos, plantillas, etc.).
