Entidades e serviços como base da lógica distribuída para o padrão de design MVC

Ao desenvolver aplicativos de escalas diferentes, torna-se cada vez mais interessante aplicar abordagens diferentes para projetar um aplicativo da web. Recentemente, a questão da separação da lógica em um grande projeto baseado no padrão de design MVC tornou-se especialmente aguda.



Entidades e serviços



Entidades



Como as tarefas se tornaram mais complexas e complexas e é impossível armazenar todos os dados no banco de dados, decidiu-se criar entidades de dados estáticos no projeto. A essência é simples - em um determinado local são armazenados dados estáticos básicos, que podem ser operados em código PHP, e sua representação em inglês é inserida no banco de dados.



Em uma visão básica, a classe Entity.php pode ter a seguinte aparência:



declare(strict_types = 1);

namespace entities;

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


Seus herdeiros devem implementar a propriedade $ map, que receberão da seguinte forma:



E1::getMap();


Além disso, a maioria dos dados estáticos irá satisfazer a lógica de recebimento. Se você precisar agrupar dados ou selecionar dados adicionais, essa lógica já está implementada nas classes herdadas.



Serviços



Os serviços são projetados para armazenar a lógica de negócios do aplicativo. Além disso, os serviços podem ser usados ​​como lógica separada da estrutura. Um serviço é uma coleção de métodos que implementa a lógica de um aplicativo. Condições que foram definidas para o serviço:



  • o serviço não deve acessar controladores e visualizações de forma independente;
  • serviço pode acessar banco de dados, modelos e entidades.


Na melhor das hipóteses, o controlador deve transmitir todos os dados necessários para o serviço, mas pode surgir uma situação em que ele precisará se referir independentemente a algum modelo para obter os dados. Não há nada de errado com isso, mas é melhor seguir a lógica de que o controlador opera com rotas de dados.



Por padrão, o serviço não implementa nenhuma lógica padrão, pois é uma execução única de uma parte do projeto. Portanto, foi decidido que a classe de serviço base não seria criada. Deve-se notar, entretanto, que é melhor criar classes básicas, mesmo que estejam vazias. Isso porque pode chegar um momento em que todos os herdeiros precisarão ter a mesma lógica ou executar algum método. Para não fazer mudanças na herança em todas as classes, é mais fácil herdar inicialmente da classe base, na qual essa situação é muito menos difícil e barata em termos de recursos temporários.



Em termos gerais, o fluxo de dados na arquitetura proposta pode ser representado da seguinte forma:



Esquema de troca de informações da arquitetura MVC com entidades e serviços



  1. Os dados ou solicitação vão para o controlador.
  2. O controlador se comunica com o modelo, serviço e entidade de forma bidirecional. Aqui ele recebe e devolve alguns dados.
  3. O serviço envia dados para o controlador, recebe ou envia dados para o modelo.
  4. O controlador envia os dados recebidos para a visualização.


Assim, verifica-se que os dados e o princípio de funcionamento da aplicação são distribuídos entre os elementos MVC básicos e os novos.



Conclusão



É importante notar que a introdução desta abordagem simplificou muito o desenvolvimento de aplicativos e o controle do fluxo de dados. A maioria dos dados foi retirada do banco de dados, o que reduziu seu tamanho e aumentou a velocidade geral do aplicativo, reduzindo o número de solicitações.



All Articles