Casando-se com agregados definidos pelo consumidor (por exemplo, contagens de SQL) com objetos de modelo 'puro'?

Question

Qual é a melhor prática de introduzir dados personalizados (normalmente voláteis) em classes de modelos de entidade? Isso pode parecer uma prática ruim primeiro, mas parece ser um cenário bastante comum. Em nosso aplicativo web recente, desenvolvemos um modelo adequado e, na maioria dos casos, estamos bem com as entidades do modelo de carregamento. Mas há casos em que não podemos dar ao luxo de carregar uma hierarquia inteira de entidades; Precisamos carregar, digamos, resultados de algumas contagens de SQL ou possivelmente algumas informações adicionais ao lado (ou incorporadas dentro) das entidades modelo. Então, basicamente, os requisitos e condições são:

1. É um aplicativo da Web em que 99.99999999999% de todas as operações são operações lidas.

2. Eles não precisam processar ou fazer qualquer lógica de negócios complicada. Só precisamos obter dados rapidamente para HTML.

3. Em vários casos críticos de desempenho, precisamos carregar resultados de agregados SQL que não se encaixam em nenhuma propriedade do modelo.

4. Precisamos de uma maneira extensível de introduzir novos dados personalizados, se necessário.

Como você geralmente resolve esse problema sem trabalhar muito em seu ORM (por exemplo, dados brutos do banco de dados)? Tenho certeza de que isso foi discutido muitas vezes, mas não consigo descobrir uma boa consulta ao Google para encontrar algo útil.

Editar: Como mais tarde percebi que a pergunta não estava muito bem formada, decidi reformulá -la e iniciar um novo.

Answer 1

Se você está apenas obtendo dados relacionais de e para um navegador, com pouco ou nenhum comportamento no meio, parece que você está tentando resolver um problema relacional com um paradigma OO.

Eu posso estar inclinado a dispensar completamente a abordagem orientada ao objeto.

A equipe de ME recentemente reescreveu um aplicativo perguntando "Qual é a coisa mais simples que pode funcionar?" e "Qual é o idioma mais próximo do problema?". Nosso novo aplicativo, substituindo um OO, acabou sendo 10 vezes menor, mais rápido e mais barato.

Utilizamos SQL, Procedimentos armazenados, bibliotecas XML no servidor DB, XSLT (para obter o HTML) e JavaScript.

Answer 2

Purist como eu iria para o padrão de decorador.http://en.wikipedia.org/wiki/Decorator_Pattern

Mas o problema é que algumas pessoas podem não precisar da flexibilidade que ela oferece. Além disso, a criação de novas classes para cada operação distinta pode parecer exagerada, mas fornece uma boa verificação de tipo de compilação.

Answer 3

A melhor prática na minha opinião é que seu aplicativo consome dados usando o Modelo de domínio padronizar. O modelo de domínio pode oferecer métodos de negócios-lógicos para fazer o tipo de consultas que fazem sentido e são relevantes para as necessidades de seu aplicativo.

Eles podem buscar resultados "ao vivo" que mapeiam diretamente para linhas de banco de dados e, portanto, podem ser editados e "salvos".

Mas, além disso, o modelo de domínio pode fornecer métodos que buscam resultados somente leitura que são complexos demais para serem facilmente salvos de volta ao banco de dados. Isso inclui o seu exemplo de resultados de consultas agregadas agrupadas e também inclui conjuntos de resultados de consulta unidos, expressões como colunas etc.

O padrão de modelo de domínio oferece uma maneira de dissociar o design OO de um aplicativo do design do banco de dados físico.