Descripción General de CodeIgniter: Estructura de aplicación
Para aprovechar al máximo CodeIgniter, debe comprender cómo está estructurada la aplicación de forma predeterminada y qué puede cambiar para satisfacer las necesidades de su aplicación. La descripción general de CodeIgniter se compone de lo siguiente:
1. Directorios predeterminados
- Aplicación
- Sistema
- Público
- Escribible
- Pruebas.
2. Modificación de ubicaciones de directorio
Una instalación nueva tiene una cantidad total de seis directorios : app/, public/, writable/, tests/, vendor/ y system/. Cada uno de estos directorios tiene un papel muy específico que desempeñar.
Aplicación
La app directorio es donde vive todo el código de su aplicación. Esto viene con una estructura de directorios predeterminada que funciona bien para muchas aplicaciones. Las siguientes carpetas conforman el contenido básico:
app/
Config/ Stores the configuration files
Controllers/ Controllers determine the program flow
Database/ Stores the database migrations and seeds files
Filters/ Stores filter classes that can run before and after controller
Helpers/ Helpers store collections of standalone functions
Language/ Multiple language support reads the language strings from here
Libraries/ Useful classes that don't fit in another category
Models/ Models work with the database to represent the business entities
ThirdParty/ ThirdParty libraries that can be used in application
Views/ Views make up the HTML that is displayed to the client
Debido a que la app directorio ya tiene un espacio de nombres, no dude en modificar la estructura de este directorio para adaptarlo a las necesidades de su aplicación. Por ejemplo, puede decidir comenzar a usar el patrón de repositorio y los modelos de entidad para trabajar con sus datos. En este caso, puede cambiar el nombre del directorio Models a Repositories y agregar un nuevo directorio.
Nota: Sin embargo, si cambia el nombre del directorio, no podrá usar el método automático de enrutamiento a los controladores y deberá definir todas sus rutas en el archivo de rutas.
Todos los archivos en este directorio viven bajo el espacio de nombres, aunque puedes cambiarlo en app/Config/Constants.php.
Sistema
Este directorio almacena los archivos que componen el propio marco. Si bien tiene mucha flexibilidad en la forma en que usa el directorio de la aplicación, los archivos en el directorio del sistema nunca deben modificarse. En su lugar, debe ampliar las clases o crear nuevas clases para proporcionar la funcionalidad deseada. Todos los archivos en este directorio viven bajo el espacio de nombres.
Público
La carpeta pública contiene la parte accesible del navegador de su aplicación web, lo que impide el acceso directo a su código fuente. Contiene el archivo principal .htaccess, index.php y cualquier activo de la aplicación que agregue, como CSS, javascript o imágenes. Esta carpeta está destinada a ser la “raíz web” de su sitio, y su servidor web estaría configurado para apuntar a ella.
Escribible
Este directorio contiene todos los directorios en los que podría ser necesario escribir en el curso de la vida de una aplicación. Esto incluye directorios para almacenar archivos de caché, registros y cualquier carga que un usuario pueda enviar. Debe agregar cualquier otro directorio en el que su aplicación necesite escribir aquí. Esto le permite mantener sus otros directorios principales sin permisos de escritura como medida de seguridad adicional.
Pruebas
Este directorio está configurado para contener sus archivos de prueba. El directorio contiene varias clases simuladas y otras utilidades que puede usar mientras escribe sus pruebas. No es necesario transferir este directorio a sus servidores de producción.
Modificación de ubicaciones de directorio
Si ha reubicado alguno de los directorios principales, puede cambiar los ajustes de configuración dentro de app/Config/Paths.php.
Descripción general de CodeIgniter: ¿Qué es MVC?
Cada vez que crea una aplicación, debe encontrar una manera de organizar el código para que sea sencillo localizar los archivos adecuados y facilitar su mantenimiento. Como la mayoría de los marcos web, CodeIgniter usa el patrón Model, View, Controller (MVC) para organizar los archivos.
Esto mantiene los datos, la presentación y el flujo a través de la aplicación como partes separadas. Cabe señalar que hay muchos puntos de vista sobre las funciones exactas de cada elemento, pero este documento describe nuestra opinión al respecto. Si lo piensa de manera diferente, puede modificar la forma en que usa cada pieza según lo necesite.
Los modelos administran los datos de la aplicación y ayudan a hacer cumplir cualquier regla comercial especial que la aplicación pueda necesitar. Las vistas son archivos simples, con poca o ninguna lógica, que muestran la información al usuario. Los controladores actúan como código de unión, ordenando datos de un lado a otro entre la vista (o el usuario que la está viendo) y el almacenamiento de datos.
En su forma más básica, los controladores y modelos son simplemente clases que tienen un trabajo específico. Obviamente, no son los únicos tipos de clase que puede usar, pero constituyen el núcleo de cómo se diseñó este marco para su uso.
Incluso tienen directorios designados en el directorio de la aplicación para su almacenamiento, aunque puede almacenarlos donde desee, siempre que tengan el espacio de nombres adecuado. Discutiremos eso con más detalle a continuación. Echemos un vistazo más de cerca a cada uno de estos tres componentes principales.
Puntos de vista
Las vistas son los archivos más simples y normalmente son HTML con cantidades muy pequeñas de PHP. El PHP debe ser muy simple, por lo general solo muestra el contenido de una variable o recorre algunos elementos y muestra su información en una tabla. Las vistas obtienen los datos para mostrar de los controladores, quienes los pasan a las vistas como variables que se pueden mostrar con simples llamadas.
También puede mostrar otras vistas dentro de una vista, por lo que es bastante sencillo mostrar un encabezado o pie de página común en cada página. Las vistas generalmente se almacenan en app/Views, pero pueden volverse difíciles de manejar rápidamente si no se organizan de alguna manera. CodeIgniter no aplica ningún tipo de organización, pero una buena regla general sería crear un nuevo directorio en el directorio Vistas para cada controlador.
Luego, nombre las vistas por el nombre del método. Esto los hace muy fáciles de encontrar más adelante. Por ejemplo, el perfil de un usuario podría mostrarse en un controlador llamado User y un método llamado profile. Puede almacenar el archivo de vista para este método en app/Views/User/Profile.php.
Ese tipo de organización funciona muy bien como un hábito básico para entrar. A veces es posible que necesite organizarlo de manera diferente. Eso no es un problema; siempre que CodeIgniter pueda encontrar el archivo, puede mostrarlo.
Modelos
El trabajo de un modelo es mantener un solo tipo de datos para la aplicación. Pueden ser usuarios, publicaciones de blog, transacciones, etc. En este caso, el trabajo del modelo consta de dos partes:
- Hacer cumplir las reglas comerciales sobre los datos a medida que se extraen o se colocan en la base de datos
- Manejar el guardado y la recuperación reales de los datos de la base de datos.
Para muchos desarrolladores, la confusión surge al determinar qué reglas comerciales se aplican. Simplemente significa que el modelo maneja cualquier restricción o requisito sobre los datos. Esto podría incluir la normalización de los datos sin procesar antes de que se guarden para cumplir con los estándares de la empresa o formatear una columna de cierta manera antes de entregarla al controlador.
Al mantener estos requisitos comerciales en el modelo, no repetirá el código en varios controladores y perderá accidentalmente la actualización de un área. Los modelos generalmente se almacenan en app/Models, aunque pueden usar un espacio de nombres para agruparse como lo necesite.
Controladores
Los controladores tienen un par de roles diferentes que desempeñar. La más obvia es que reciben información del usuario y luego determinan qué hacer con ella. Esto a menudo implica pasar los datos a un modelo para guardarlos o solicitar datos del modelo que luego se pasan a la vista para mostrarlos. Esto también incluye cargar otras clases de utilidad, si es necesario, para manejar tareas especializadas que están fuera del alcance del modelo.
La otra responsabilidad del controlador es manejar todo lo relacionado con las solicitudes HTTP: redireccionamientos, autenticación, seguridad web, codificación, etc. En resumen, el controlador es donde se asegura de que las personas puedan estar allí y obtengan los datos. necesitan en un formato que puedan usar. Los controladores generalmente se almacenan en app/Controllers , aunque pueden usar un espacio de nombres para agruparse como lo necesite.
Archivos de carga automática
Cada aplicación consta de una gran cantidad de clases en muchos lugares diferentes. El marco proporciona clases para la funcionalidad principal. Su aplicación tendrá una serie de bibliotecas, modelos y otras entidades para que funcione. Es posible que tenga clases de terceros que esté utilizando su proyecto.
Hacer un seguimiento de dónde está cada archivo y codificar esa ubicación en sus archivos en un gran dolor de cabeza y algo muy propenso a errores. Ahí es donde entran los cargadores automáticos. CodeIgniter proporciona un cargador automático muy flexible que se puede usar con muy poca configuración.
Puede ubicar clases de espacio de nombres individuales que se adhieren a las estructuras de directorio de carga automática PSR-4. El cargador automático funciona muy bien por sí solo, pero también puede funcionar con otros cargadores automáticos como Composer. (O incluso con sus propios cargadores automáticos personalizados, si es necesario).
Debido a que todos están registrados a través de spl_autoload_register, estos funcionan en secuencia y no interfieren entre sí. El cargador automático siempre está activo, registrándose al comienzo de la ejecución del marco.
Configuración
La configuración inicial se realiza en app/Config/Autoload.php. Este archivo contiene dos matrices principales: una para el mapa de clases y otra para los espacios de nombres compatibles con PSR-4.
Espacios de nombres
El método recomendado para organizar sus clases es crear uno o más espacios de nombres para los archivos de su aplicación. Esto es más importante para cualquier clase relacionada con la lógica empresarial, clases de entidad, etc. La matriz en el archivo de configuración le permite asignar el espacio de nombres al directorio en el que se pueden encontrar esas clases:
<?php
$psr4 = [
'App' => APPPATH,
'CodeIgniter' => SYSTEMPATH,
];
La clave de cada fila es el propio espacio de nombres. Esto no necesita una barra diagonal inversa. El valor es la ubicación del directorio en el que se pueden encontrar las clases. Deben tener una barra diagonal final. De forma predeterminada, la carpeta de la aplicación es un espacio de nombres para el espacio de App nombres.
Si bien no está obligado a asignar un espacio de nombres a los controladores, bibliotecas o modelos en el directorio de la aplicación, si lo hace, se encontrarán en el espacio de nombres. Puede cambiar este espacio de nombres editando el archivo app/Config/Constants.phpAPP_NAMESPACE y configurando el nuevo valor del espacio de nombres en la configuración:
<?php
define('APP_NAMESPACE', 'App');
Deberá modificar cualquier archivo existente que haga referencia al espacio de nombres actual.
Mapa de clase
CodeIgniter utiliza ampliamente el mapa de clase para obtener las últimas onzas de rendimiento del sistema al no golpear el sistema de archivos con llamadas adicionales. Puede usar el mapa de clase para vincular a bibliotecas de terceros que no tienen espacios de nombres:
<?php
$classmap = [
'Markdown' => APPPATH . 'third_party/markdown.php',
];
La clave de cada fila es el nombre de la clase que desea localizar. El valor es la ruta para ubicarlo.
Compatibilidad con compositores
La compatibilidad con Composer se inicializa automáticamente de forma predeterminada. De forma predeterminada, busca el archivo de carga automática de Composer en . Si necesita cambiar la ubicación de ese archivo por algún motivo, puede modificar el valor definido en app/Config/Constants.php .ROOTPATH . ‘vendor/autoload.php‘
Descripción general de CodeIgniter: ¿Qué son los Servicios?
Los Servicios en CodeIgniter 4 brindan la funcionalidad para crear y compartir nuevas instancias de clase. Se implementa como la clase Config\Services. Todas las clases principales dentro de CodeIgniter se proporcionan como “servicios”. Esto simplemente significa que, en lugar de codificar un nombre de clase para cargar, las clases para llamar se definen dentro de un archivo de configuración muy simple. Este archivo actúa como un tipo de fábrica para crear nuevas instancias de la clase requerida.
¿Por qué utilizar Servicios?
Un ejemplo rápido probablemente aclarará las cosas, así que imagine que necesita obtener una instancia de la clase Timer. El método más simple sería simplemente crear una nueva instancia de esa clase:
<?php
$timer = new \CodeIgniter\Debug\Timer();
Y esto funciona muy bien. Hasta que decidas que quieres usar una clase de temporizador diferente en su lugar. Tal vez este tenga algunos informes avanzados que el temporizador predeterminado no proporciona. Para hacer esto, ahora debe ubicar todas las ubicaciones en su aplicación en las que ha utilizado la clase de temporizador.
Dado que es posible que los haya dejado en su lugar para mantener un registro de rendimiento de su aplicación en ejecución constante, esta podría ser una forma de manejar esto que consume mucho tiempo y es propensa a errores. Ahí es donde los servicios son útiles. En lugar de crear la instancia nosotros mismos, dejamos que una clase central cree una instancia de la clase para nosotros.
Esta clase se mantiene muy simple. Solo contiene un método para cada clase que queramos usar como servicio. El método generalmente devuelve una instancia compartida de esa clase, pasando cualquier dependencia que pueda tener. Luego, reemplazaríamos nuestro código de creación de temporizador con un código que llame a esta nueva clase:
<?php
$timer = \Config\Services::timer();
Cuando necesite cambiar la implementación utilizada, puede modificar el archivo de configuración de servicios y el cambio se produce automáticamente en toda su aplicación sin que tenga que hacer nada. Ahora solo necesita aprovechar cualquier nueva funcionalidad y estará listo para comenzar. Muy simple y resistente a errores.
