Em nossa API, temos alguns tipos de dados centrais que precisam ser "decorados" (por assim dizer) após a recuperação do banco de dados com valores calculados. O banco de dados é acessado através de um ORM que segue uma dinâmica de Tabela / Entidade fortemente inspirada na camada de banco de dados do CakePHP 3, onde um objeto de Tabela é usado como intermediário entre o banco de dados e o aplicativo que recebe e distribui linhas como instâncias de objeto de modelo. Portanto, em vez de apenas recuperar dados do banco de dados e retornar essas linhas, precisamos pré-processar os dados retornados antes que sejam realmente utilizáveis. Aqui estão alguns casos de uso que surgiram para explicar melhor o que quero dizer:
- Os objetos têm valores numéricos que são traduzidos para rótulos amigáveis ao usuário (normalmente essa é a lógica que eu manteria apenas no cliente, mas por razões de segurança comercial, alguns desses dados precisam ser mantidos apenas no servidor, reconhecidamente caso borda)
- Os objetos precisam ter um valor de classificação associado, extraído da classificação adicionada mais recentemente
- Com base em uma combinação de valores calculados como este e valores armazenados, um objeto de planejamento complexo é construído
Por si só, qualquer um desses individualmente é realmente muito fácil de executar com uma map()operação simples sobre o conjunto de resultados retornado. O mesmo se aplica a quando você deseja vários valores calculados, basta realizar mais operações de mapa para calcular e adicionar esses campos conforme necessário.
Dito isto, essa abordagem tem duas grandes desvantagens:
- Isso significa que você precisa executar uma etapa adicional de pós-processamento em todos os lugares em que deseja trabalhar com esses valores calculados, o que não é particularmente SECO
- Algumas dessas transformações dependem de outras transformações sendo executadas primeiro, caso contrário, elas simplesmente não têm os dados disponíveis para trabalhar com
Para lidar com ambos, estive pensando que a melhor abordagem seria mover esse código para o ORM e modificá-lo para que a interface permita (externamente) o acesso aos campos virtuais calculados da mesma maneira que lida com as colunas do banco de dados . Internamente, ele poderia mapear esses campos virtuais para funções de transformação e determinar internamente quaisquer possíveis transformações de dependência necessárias para resolver o segundo problema.
(À parte, estou pensando se isso também elimina a necessidade de as linhas retornadas serem objetos reais, em oposição a hashes simples. No momento, cada linha instancia um novo objeto com os dados do campo definidos, mas se todo o cálculo ou Como a modificação dos dados é removida do modelo, o objeto se torna um conjunto de propriedades - um mapa de hash, essencialmente, sem lógica interna própria. O que, na verdade, pode não ser uma coisa ruim)