Olá,
Bom …é o seguinte:
Tenho uma Entidade Ex. ResumoReceita…
public class ResumoReceita{
private Empresa empresa;
private Produto produto;
private Map<String, BigDecimal> valores;
private Map<String, BigDecimal> emprestimos;
private Map<String, BigDecimal> ressarcimentos;
Uma determinada consulta retorna uma coleção de ResumoReceita.
Como estou montando “um painel” com gráficos uso essa mesma coleção, mas para cada gráfico é necessário agrupar os dados de maneira diferente.
Ex.:
Meu gráfico principal será de Receita por Empresa. Ao clicar em uma barra (ou seja uma empresa) abrem vários outro gráficos com informações da empresa.
- 10 maiores empréstimos desta empresa mês a mês.
- Os produtos mais vendidos mês a mês.
Etc…etc…
Minha dúvida:
Quem agrupa estas outras informações para ser apresentado na VIEW?
Usando Strus2 minha Action tem a coleção de ResumoReceita então eu devo criar vários métodos na própria Action que monte Lists (ou Maps) com as informações necessárias para cada um dos gráficos??
Eu pensei em fazer assim, mas minha Action ta ficando gigante a medida que o cliente pede um novo gráfico.
Pensei em delegar a tarefa de agrupar os dados para outro “Componente”…(e isso envolve percorrer a Coleção de ResumoReceita, extrair os dados necessários, fazer cálculos e agrupamentos e devolver um List/Map/Set para a View)
Obrigado.
Tente agrupar cada um desses gráficos em uma classe separada. A sua action está perdendo coesão, está ficando inchada. Você poderia criar, por exemplo, uma classe RelatorioInformacoesEmpresa que conteria a lógica para obter os dados e realizar os cálculos. Esses relatórios seriam modelados como objetos do domínio do sistema. Assim você consegue distribuir melhor responsabilidades, aumentar a coesão e diminuir o acoplamento das suas actions.
Duas leituras:
Refactoring, do Fowler (a introdução dele mostra um exemplo que se aplica ao seu caso), e
Applying UML and Patterns, do Craig Larman (a parte de projeto OO dele é bem legal)
[quote=neófito]Tente agrupar cada um desses gráficos em uma classe separada. A sua action está perdendo coesão, está ficando inchada. Você poderia criar, por exemplo, uma classe RelatorioInformacoesEmpresa que conteria a lógica para obter os dados e realizar os cálculos. Esses relatórios seriam modelados como objetos do domínio do sistema. Assim você consegue distribuir melhor responsabilidades, aumentar a coesão e diminuir o acoplamento das suas actions.
Duas leituras:
Refactoring, do Fowler (a introdução dele mostra um exemplo que se aplica ao seu caso), e
Applying UML and Patterns, do Craig Larman (a parte de projeto OO dele é bem legal)
[/quote]
Ótimo…
por uma incrivel conhecidencia essas são duas das minhas próximas leituras.
Que bom que ajudei.
O importante é ter em mente que você está desenvolvendo um sistema orientado a objetos, com uma linguagem orientada a objetos. Não faz muito sentido ter essas ferramentas à mão e não usá-las. As classes do seu sistema devem ter estado e comportamento, como qualquer objeto. Procure criá-las realmente como objetos, e não apenas um aglomerado de dados e funções que executam todo tipo de tarefa.
Outra leitura legal, que fala sobre o assunto:
http://www.fragmental.com.br/wiki/index.php/Fantoches
[quote=neófito]…Esses relatórios seriam modelados como objetos do domínio do sistema.
[/quote]
A idéia da classe separada eu já adotei, mas não estou visualizando ele como fazendo parte do meu domain model.
:roll:
É apenas uma forma diferente de visualização (agrupamento) dos dados do meu domínio.
O que você acha??..
Digo isso, mas não sei onde se encaixaria este objeto.
Você tem alguma regra de negócio (pesquisa, cálculo, agrupamento, etc…) para criar o relatório? Se sim, ele deve ser uma classe de domínio. O modelo de domínio nada mais é do que uma abstração do que existe no mundo real. No caso do elemento não existir, é você que está pesquisando e modelando como deveria ser o domínio, com base nas informações obtidas de experts do domínio.
Talvez não uma classe, mas um método em uma classe que contenha a informação necessária, ou parte dela, para criar o relatório. Mas lembre-se que se houver processamento demais o correto é separá-lo em um classe.
