valores calculados de armazenamento em cache (somas / totais) no banco de dados

votos
0

Considere o modelo de objeto seguir (- >> indica coleção):

Cliente-> ordens

Ordens - >> OrderLineItems-> Product {preço}

O aplicativo está focada em processamento de pedidos, então a maioria das tabelas de tempo mostrando todas as ordens que correspondem a determinados critérios são usados ​​na interface do usuário. 99% do tempo eu só estou interessado em exibir a soma de LineTotals, não os LineTotals individuais.

Pensando nisso ainda, também pode haver vários pagamentos (transferências bancárias, cheque, cartão de crédito, etc.) associados a cada fim, mais uma vez, im interessados ​​apenas na soma de dinheiro que eu recebi.

Ao consultar a base de dados para uma ordem, eu não quero selecionar todos os pedidos e, em seguida, para cada ordem, seus pagamentos e LineItems.

Minha idéia era para armazenar o associado cada ordem com um objeto status, o cache de todas as somas e status de um pedido, melhorando o desempenho da consulta por ordens de magnitude e também apoiar cenários de consulta para as ordens não pagos, pago encomendas, encomendas devido etc.

Isso evita que a lógica de domínio (por exemplo, quando uma ordem é considerada a ser pago) vaze para consultas de banco de dados. No entanto, ele coloca a responsabilidade de manter as somas até à data. O sistema tem geralmente pontos bem definido, onde que precisa acontecer, por exemplo, entrar ou integrando pagamentos, criar / modificar uma ordem.

Até agora eu tenho usado observáveis ​​Coleções, que desencadeiam recálculos de Estado quando os itens são adicionados ou removidos, ou certas propriedades nos itens são atualizados. Pergunto-me onde a lógica para tudo o que deve ser colocado sob uma perspectiva ddd. Parece estranho para mim para forçar toda a fiação evento e lógica de cálculo na raiz agregada.

Publicado 26/08/2009 em 23:45
fonte usuário
Em outras línguas...                            


3 respostas

votos
1

Você precisa expressar a intenção de uma solicitação em uma interface intenção reveladora, de modo que seus repositórios pode entender o que exatamente você quer fazer e reagir em conformidade. Neste caso, a interface revela intenção, não para outros desenvolvedores, mas para outro código. Então, se você quer um estado ou total, criar uma interface que revela essa intenção e solicitar um objeto desse tipo a partir de seu repositório. O repositório pode, então, criar e retornar um objeto de domínio que encapsula fazendo exatamente o trabalho necessário para calcular o total e não mais do que isso.

Além disso, seu DAL pode inteligentemente escolher qual estratégia de busca para aplicar a partir da interface você solicitar, ou seja, o carregamento lento para situações em que você não precisa para acessar objetos filho e carregamento ansioso onde você faz.

Udi Dahan tem alguns grandes posts sobre isso . Ele tem escrito e falado sobre a aplicação de interfaces de revelar intenção para este problema, que ele chama fazendo papéis explícita .

Respondeu 03/09/2009 em 23:55
fonte usuário

votos
0

"Parece estranho para mim para forçar toda a fiação evento e lógica de cálculo na raiz agregada."

Isso é geralmente uma chamada para um «serviço».

Respondeu 15/09/2009 em 22:24
fonte usuário

votos
0

Eu recomendo olhar em OR (objeto relacional) mapeadores que suportam LINQ. Para citar os dois mais primárias, LINQ to SQL e Entity Framework, ambos da Microsoft. Acredito LLBLGen também suporta LINQ agora, e nHibernate tem algumas soluções cozido meio LINQ que você poderia tentar. Minha recomendação principal é Entity Framework v4.0, que está disponível através do .NET 4.0 betas ou o Visual Studio 2010 Beta.

Com um LINQ habilitado ou mapeador, você pode facilmente consultar a informação agregada que você precisa de forma dinâmica, em tempo real, usando apenas o seu modelo de domínio. Não há necessidade de lógica de negócios para vazar em sua camada de dados, porque você geralmente não vai usar procedimentos armazenados. OR mappers gerar SQL parametrizado para você na mosca. LINQ combinado com OR mappers é uma ferramenta extremamente poderosa que lhe permite não só consulta e recuperar entidades e gráficos entidade, mas também buscar por projeções de dados do seu modelo de domínio ... permitindo a recuperação de conjuntos de dados personalizados, agregações, etc. através de um único modelo conceitual.

Respondeu 27/08/2009 em 07:56
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more