Hay dos estructuras principales de base de código que he visto cuando se trata de marcos MVC. El problema es que ambos parecen tener un error organizacional que los acompaña.
MVC estándar
/controller
/model
/view
Problema: no hay separación de componentes relacionados (foro, blog, usuario, etc.)
MVC modular
/blog
/controller
/model
/view
/user
/controller
/model
/view
/forum
/controller
/model
/view
Elegir el sistema basado en módulos te deja con un problema.
- Nombres largos (Forum_Model_Forum = forum / model / forum.php) (como Zend)
- ¿El sistema de archivos busca utilizando
is_file()para encontrar qué carpeta tiene el modelo de foro? (Como Kohana)
¿Hay alguna otra estructura MVC que funcione bien cuando se trata de separar diferentes módulos? ¿Hay beneficios de estas estructuras que me faltan?
web-applications
mvc
web-framework
file-structure
Xeoncross
fuente
fuente
Respuestas:
Tratar:
Sus modelos son el corazón de su aplicación. Debe diseñarlos y codificarlos como un paquete independiente. Los controladores son solo clientes de su modelo, que pasan a traducir la actividad del usuario en acciones para su modelo. Una vista es solo una forma particular de mostrar datos de su modelo. Si su aplicación crece, podría ir aún más lejos al separar a los clientes del modelo:
Esto debería hacer obvio que puede tener múltiples clientes, que todos de una forma u otra, interactúan con un solo modelo.
fuente
;)
Encontré la mejor estructura para un Marco MVC / HMVC combinado. Para lo principal, necesita usar controladores / modelos / vistas base ... pero para los componentes individuales de los módulos del curso ...
Entonces, en mi estructura de marco MVC / HMVC se ve así:
Además, si lo necesito, agrego módulos de bibliotecas, i18n o helpers.
La convención de nomenclatura es fácil, para los controladores y modelos agrego el sufijo _Controller y _Model. Para los controladores y modelos de los módulos, también agrego un prefijo con el nombre del módulo, por ej. El perfil del controlador en el módulo Usuario se denominará User_Profile_Controller.
Por lo tanto, es muy fácil y rápido encontrar lo que necesita.
fuente
El nombramiento sistemático de las clases ayuda a evitar conflictos de nombres entre componentes. El nombramiento prolongado de clases no es probable que imponga sanciones severas de rendimiento. Encuentro este esquema de nombres bastante útil cuando se codifica porque es fácil ver de dónde viene.
Esto depende en gran medida de cómo se haya implementado el sistema, pero la estructura del sistema de archivos generalmente sigue una convención que permite el acceso inmediato al componente correcto sin búsquedas exhaustivas del sistema de archivos.
Aquí hay un ejemplo, supongamos que se va a utilizar el componente del foro:
Información:
Nombre del controlador: índice
$ controller_path = BASEDIR. 'módulo /'. $ nombre_componente. '/controlador/' . $ nombre_controlador. '.php';
También es importante tener en cuenta que hay literalmente cientos de consultas del sistema de archivos al iniciar un sitio web típico, por lo que agregar algunas no va a dañar.
fuente
Tengo trabajo con sitios web que comenzaron con el primer "MVC estándar", pero eventualmente se convirtieron en el "MVC modular".
Si está haciendo un sitio web pequeño y no tiene mucha experiencia, puede comenzar con el "MVC estándar". Si ya sabe que el sitio web va a ser muy complejo y grande, entonces tendrá que acostumbrarse al "MVC Modular", será un poco difícil al comienzo, pero, eventualmente, se acostumbrará a eso.
fuente
De hecho, estoy trabajando en un marco y utilizo una combinación de estructura de directorios basada en módulos y de forma libre. Mi estructura predeterminada para el código del sitio que usa el marco es:
También puede tener una carpeta de módulo que no se relacione con un controlador y hay una llamada Core por defecto que se usa para almacenar plantillas de todo el sitio como el encabezado y el pie de página. Esto para mí da lo mejor de ambos mundos. Puede saber fácilmente dónde está el controlador, ya que hay un controlador por carpeta, pero para clases como modelos no necesita buscar dónde están los archivos, ya que están en un directorio (que también mantiene los nombres de los modelos más limpios) .
La forma en que cargo los archivos es un poco diferente, ya que le permito al usuario configurar los diferentes directorios sobre dónde podrían estar las clases, así que analizo los directorios inicialmente y almaceno todas las ubicaciones de los archivos de clase en un archivo json y luego lo uso para buscar rápidamente todas las demás solicitudes (aunque estoy buscando formas de mejorar esto).
fuente
La respuesta a esto ha sido dictada por la Propuesta PSR-0 que todos los sistemas grandes están comenzando a adaptarse, o que han adoptado ahora.
La estructura es:
Esto significa que no hay nada que pueda hacer para arreglar nombres largos de archivos:
Esto también significa que debe usar archivos tontos de mayúsculas y minúsculas en lugar de todas las minúsculas (si no lo hace, las bibliotecas de terceros no funcionarán).
fuente
La solución de Mathiases tiene mucho sentido. Y el uso de su estructura de carpetas no impide tener contenido conectable, por ejemplo, agregar un / galería / independiente podría verse así
Ahora tenemos un "modelo" compartido e independientes si es necesario
fuente