Entidades y servicios como base de la lógica distribuida para el patrón de diseño MVC

Al desarrollar aplicaciones de diferentes escalas, se vuelve cada vez más interesante aplicar diferentes enfoques para diseñar una aplicación web. Recientemente, el problema de la separación de la lógica en un gran proyecto basado en el patrón de diseño MVC se ha vuelto especialmente agudo.

Entidades y servicios

Entidades

Dado que las tareas se han vuelto más complicadas y complejas, y es imposible almacenar todo en la base de datos, se decidió crear entidades de datos estáticos en el proyecto. La esencia es simple: en un lugar determinado se almacenan datos estáticos básicos, que se pueden operar en código PHP, y su representación en inglés se ingresa en la base de datos.



En una vista básica, la clase Entity.php podría verse así:

declare(strict_types = 1);

namespace entities;

class Entity {
	protected static $map;
	
	public static function getMap():array {
		return static::$map;
	}
}

Sus herederos deben implementar la propiedad $ map, que recibirán de la siguiente manera:

E1::getMap();

Además, la mayoría de los datos estáticos satisfarán la lógica de recepción. Si necesita agrupar datos o seleccionar datos adicionales, esta lógica ya está implementada en las clases heredadas.

Servicios

Los servicios están diseñados para almacenar la lógica empresarial de la aplicación. Además, los servicios se pueden utilizar como una lógica separada del marco. Un servicio es una colección de métodos que implementa la lógica de una aplicación. Condiciones que se definieron para el servicio:

• el servicio no debe acceder de forma independiente a los controladores y vistas;
• El servicio puede acceder a bases de datos, modelos y entidades.

En el mejor de los casos, el responsable del tratamiento debe transmitir todos los datos necesarios al servicio, pero puede surgir una situación en la que deba consultar de forma independiente algún modelo para obtener los datos. No hay nada de malo en eso, pero es mejor adherirse a la lógica de que el controlador opera rutas de datos.



Por defecto, el servicio no implementa ninguna lógica estándar, ya que es una ejecución única de una parte del proyecto. Por lo tanto, se decidió que no se crearía la clase de servicio base. Sin embargo, cabe señalar que es mejor crear clases base incluso si están vacías. Esto se debe a que puede llegar un momento en el que todos los herederos necesiten tener la misma lógica o ejecutar algún método. Para no realizar cambios en la herencia en todas las clases, es más fácil heredar inicialmente de la clase base, en la que esta situación es mucho menos complicada y más económica en cuanto a recursos temporales.



En términos generales, el flujo de datos en la arquitectura propuesta se puede representar de la siguiente manera:

1. Los datos o la solicitud van al responsable del tratamiento.
2. El responsable del tratamiento se comunica con el modelo, el servicio y la entidad de forma bidireccional. Aquí recibe y devuelve algunos datos.
3. El servicio envía datos al controlador, recibe o envía datos al modelo.
4. El controlador envía los datos recibidos a la vista.

Así, resulta que los datos y el principio de funcionamiento de la aplicación se distribuyen entre los elementos básicos de MVC y los nuevos.

Conclusión

Vale la pena señalar que la introducción de este enfoque ha simplificado enormemente el desarrollo de aplicaciones y ha controlado el flujo de datos. La mayoría de los datos se extrajeron de la base de datos, lo que redujo su tamaño y aumentó la velocidad general de la aplicación al reducir el número de solicitudes.