2011-10-31 94 views
15

Estoy tratando de limpiar el marco en el que he estado trabajando. En este momento, el sitio se compone de los siguientes directorios:Estructura de directorio para MVC

Models 
Views 
Controllers 
Helpers (Miscellaneous functions) 
Libraries (Universal classes, like library and session management) 
Images 
Style 

Cada vez que una página se llama, la secuencia de comandos router busca el controlador asociado, por lo que habría una instancia thesite.com/login Login_Controller a '/ controladores/login. php 'El problema al que me enfrento es que el script del enrutador mismo se siente como un tipo de controlador, al igual que view.php, que maneja los datos de formateo para ser manejados por la vista apropiada. Pero estos no son exactamente como los controladores de página, ya que controlan el MVC en sí. Todavía soy algo nuevo en esta arquitectura, y tengo curiosidad de cómo alguien con más experiencia podría organizar esto.

¿Podría clasificar el enrutador y ver los controladores como bibliotecas, o sería mejor crear un subdirectorio dentro/controladores llamado 'páginas', o alguna otra idea? Muchas gracias.

+1

Por lo general, las carpetas que mencionas arriba estarían en una carpeta llamada 'aplicación', por ejemplo, y el código que realmente ejecuta tu infraestructura se almacenaría en su propia carpeta llamada 'núcleo', por ejemplo. –

+0

También es probable que desee mover la mayor parte de este fuera de su directorio público y utilizar una ruta de inclusión para tomar los archivos. Supongo que ahora está en un directorio público debido a la carpeta Style and Images. – dqhendricks

+0

Entonces, ¿tendría modelos, vistas, directorios de controladores en la raíz del sitio y luego/application/controller para router.php y view.php? Me pregunto qué se considera estándar, en todo caso. – dlwiest

Respuesta

8

sugeriría a seguir la estructura de directorios Symfony 1.x. Claro, lógico, seguro.

Extracto del libro "The definitive guide to Symfony" por Fabien Potencier & François Zaninotto:

apps/ 
    frontend/ 
    backend/ 
cache/ 
config/ 
data/ 
    sql/ 
doc/ 
lib/ 
    model/ 
log/ 
plugins/ 
test/ 
    bootstrap/ 
    unit/ 
    functional/ 
web/ 
    css/ 
    images/ 
    js/ 
    uploads/ 
  • aplicaciones/ Contiene un directorio para cada aplicación del proyecto (normalmente, frontend y backend para la parte pública y la parte)
  • caché/ Contiene la versión en caché de la configuración y (si la activa) la versión de caché de las acciones y plantillas del proyecto. El mecanismo de caché (detallado en el Capítulo 12) usa estos archivos para acelerar la respuesta a las solicitudes web. Cada aplicación tendrá un subdirectorio aquí, que contiene PHP preprocesado y archivos HTML.
  • config/ Contiene la configuración general del proyecto.
  • data/ Aquí puede almacenar los archivos de datos del proyecto, como un esquema de base de datos, un archivo SQL que crea tablas, o incluso un archivo de base de datos SQLite.
  • doc/ Almacena la documentación del proyecto, incluidos sus propios documentos y la documentación generada por PHPdoc.
  • lib/ Dedicado a clases o bibliotecas extranjeras. Aquí puede agregar el código que necesita para compartir entre sus aplicaciones.El subdirectorio modelo / almacena el modelo de objetos del proyecto (descrito en el Capítulo 8).
    • log/ Almacena los archivos de registro correspondientes generados directamente por Symfony. También puede contener archivos de registro del servidor web, archivos de registro de base de datos o archivos de registro de cualquier parte del proyecto. Symfony crea un archivo de registro por aplicación y por entorno (los archivos de registro son discutidos en el Capítulo 16).
  • plugins/ Almacena los plugins instalados en la aplicación (plugins se discuten en el capítulo 17).
  • test/ Contiene pruebas unitarias y funcionales escritas en PHP y compatibles con el marco de prueba symfony (discutidas en el Capítulo 15). Durante la configuración del proyecto, Symfony agrega automáticamente algunos resguardos con algunas pruebas básicas.
  • web/ La raíz para el servidor web. Los únicos archivos accesibles desde Internet son los ubicados en este directorio.
+0

El enlace está muerto. – Mike

+0

Gracias por la información Mike; actualizó mi respuesta + copia/pegó/fragmento relevante formateado del documento original –

6

No me llamaría un experto, pero una solución sería mover su 'marco' lejos de la implementación. Lo que quiero decir es mover su 'enrutador', 'view.php' y otras clases de framework a alguna ubicación externa que luego incluirá en su index.php o en cualquier archivo que sea su punto de acceso.

Entonces, solo el contenido estaría en el directorio de la aplicación real, mientras que todos los archivos de la estructura quedarían en una ubicación a la que no se puede acceder a través del servidor web.

Sólo una idea :)

18

yo sugeriría que para estudiar la estructura de directorios de un marco, como Symfony2 o yü

Esto es lo que elegí la mía:

public_html/    (for public files) (should be public, place only index.php in here) 
public_html/css/ 
public_html/images 
public_html/js   (for your js files, or custom generated ones) 
lib/      (for my libs) (should be private) 
lib/vendor/    (for 3rd party libs) 
application/    (for the whole app) (should be private) 
application/class   (classes that make the app work such as mainApp, Controller, Model, View, etc...) 
application/class/model (all the models) 
application/class/view (all the views) 
application/class/view/html (templates used by the views) 
application/class/controller (all controllers) 
application/class/helper (helper functions) 
application/class/lib  (libs that you develop for the application) 
application/template  (layout and/or templates for the application) 
application/conf   (config files) 
application/log   (log files) 
application/cron   (scheduled jobs) 
application/database  (for database migration scripts) 
... 

También puede utilizar el archivo de convenciones de nombres, tales como: YourClassName.class.php para clases, YourView.phtml para sus vistas, etc. Consulte un marco y aprenderá cómo estructurarlo bien y la aplicación.

+0

Gracias, eso es muy útil. Supongo que view.php iría/vería, y luego todo el resto de los archivos de la plantilla entrarían en/view/html, pero ¿dónde recomendarías poner el router.php? Es prácticamente el punto de entrada al resto del sistema. – dlwiest

+0

para el enrutador Uso /index.php, es el programa de arranque, dentro de él utilizo una instancia de la clase mainApp, que gestiona cualquier "operación global" (enrutamiento, almacenamiento en caché, invocación del controlador, registro, errores) ... aunque lo hago el material de enrutamiento a través del módulo mod_rewrite de apache –

+0

sobre la vista ... estás pero estoy editando mi respuesta para que muestre más claro lo que intento explicar –

Cuestiones relacionadas