Si te encuentras con alguna parte que te causa duda puedes comentarlo y te responderemos lo mas rápido que podamos.
Solución:
No. PHP es lo que tú haces de él. Pueden ser archivos planos muy simples, o como quieras.
Dicho esto, hay algunos estándares de codificación acordados, pero no hay “aplicación” de dichos estándares. Se llaman PSR (Recomendación de estándares PHP). Hay un trasfondo aquí: http://net.tutsplus.com/tutorials/php/psr-huh/
Puede ver los estándares uno por uno aquí: http://www.php-fig.org/psr/
La mayoría de los marcos principales siguen estos estándares, y si va a usar uno, puede ser más fácil seguir la corriente.
Nuevamente, cada marco, proyecto, complemento, programa, etc., tiene diferentes diseños con diferentes estructuras de proyecto. Una estructura común es algo como esto:
-framework_dir
-public_html
-js
-img
-css
-index.php
-protected/private
-controllers
-models
-views
-etc
Luego usan el .htaccess archivo para bloquear el acceso a los directorios protegidos. Nuevamente, esta es solo la representación común que he visto en varios marcos. Si estás haciendo un proyecto personal, simplemente usa algo que te resulte cómodo. Cada marco le dará una biblioteca diferente o una forma de acceder a los datos. No hay “capas”, pero nuevamente cada marco tiene objetos que manejan diferentes áreas (correo electrónico, base de datos, caché, http, registros, etc.). Debido a que hay docenas de populares, solo depende de usted encontrar lo que se ajuste a su filosofía o proyecto. Mire algunos de los videos de blog de 5 minutos, vea qué funciona y luego pruébelo durante un par de días. Si no te gusta, cambia a otro.
Con la invención de Composer, las personas ahora tienen un lugar central para registrar sus proyectos para que el mundo los consuma, y otras personas ahora pueden mirar esa base de código y ver similitudes.
El resultado es este: https://github.com/php-pds/skeleton
En breve:
If a package has a root-level directory for ...
... then it MUST be named:
command-line executables bin/
configuration files config/
documentation files docs/
web server files public/
other resource files resources/
PHP source code src/
test code tests/
Este estándar no hace más recomendaciones sobre qué directorios deben existir a continuación. src o public.
La tarea de organizar sus archivos fuente de PHP dentro de cualquiera de estos directorios aún depende de usted, pero hay sugerencias descritas en este artículo con las que estaría de acuerdo: ordenar por tipo (controlador, entidad, servicio) u ordenar por característica (usuario, inicio de sesión, carrito, catálogo, artículo, comentario): este último mantiene todo el código que pertenece a una función en el directorio (o algunos subdirectorios), lo que a menudo parece ser la mejor organización de archivos.
Al organizar por tipo, se encontrará saltando entre directorios con bastante frecuencia, y tampoco obtendrá una buena visión general de lo que trata el código: siempre tendrá “Controlador”, pero rara vez tendrá “StampCollection”.
Tiendo a usar un basado en funciones estructura de carpetas para mis proyectos backend. Cada carpeta de funciones tiene su propio controlador, administrador y archivo de rutas. Esto funciona bien para API-backends. Se parece a https://blog.nikolaposa.in.rs/2017/01/16/on-structuring-php-projects/
Por ejemplo, tenemos una característica de Cliente con CustomerController, CustomerRepository, CustomerRoutes,..
Mi estructura de carpetas se ve así:
- build/
-- phpdox.xml
-- phpmd.xml
-- phpunit.dist.xml
- config/
- public/
-- .htaccess
-- index.php
-- assets/
- src/
-- Customer/
--- CustomerController.php
--- CustomerRepository.php
--- Customer.php
--- customer.routes.php
- tests/
- vendor/
composer.json
.gitignore
Comentarios y valoraciones
Si te mola la invitación, puedes dejar una reseña acerca de qué te ha parecido este escrito.