Em outro artigo (www.adianti.com.br/forum/pt/view_876), eu explico que devemos privilegiar o uso de objetos, seus métodos e relacionamentos mais do que o uso de SQL em uma aplicação de negócios. Devemos sempre que possível usar mecanismos do próprio framework para cuidar da persistência dos objetos - como o Active Record - e dos relacionamentos entre eles. Na grande maioria das situações (formulários de inserção e atualização, datagrids com listagens e delação de registros), podemos usar os mecanismos do próprio framework para persistência, como os métodos store(), load() e delete() da classe TRecord (que manipula um objeto de cada vez), bem como os métodos load(), delete() e count() da classe TRepository (que manipula um conjunto de objetos). Devemos deixar as complexas expressões SQL somente para os casos em que elas são realmente necessárias.

Uma situação em que o usos e instruções SQL é praticamente indispensável é em relatórios. Por que em relatórios frequentemente precisamos cruzar muitas tabelas, fazer uso de subconsultas, expressões matemáticas, bem como recursos específicos do banco de dados (funções de georreferência, geométricas, data warehouse, etc). Além disso, existem consultas cujo resultado só faz sentido a partir do cruzamento de várias tabelas. Realizar tais operações usando apenas objetos teria um custo muito alto, tendo em vista que para montar um relatório teríamos de percorrer milhares de objetos de uma classe e, a partir desses, buscar informações em objetos relacionados. Claro que essas questões de desempenho caem por terra com o advento de novas tecnologias que permitem o uso de banco de dados em memória. Mas como isso ainda não é uma realidade para as maiorias, vamos adotar uma estratégia simples e funcional.

Então, como fazer um relatório usando o Adianti Framework? A maneira mais simples é criar uma VIEW no banco de dados para encapsular o SQL do relatório, e a partir de então manipular essa VIEW por meio de uma classe Active Record (TRecord) e repositório (TRepository).

Vamos imaginar que nossa query busca dados de pessoas e títulos, onde os títulos já estão vencidos e as pessoas residem na cidade cujo ID=10. Claro que essa é uma query bastante simples. Mas para nosso exemplo é suficiente. Poderíamos pensar aqui queries cruzando até 10 tabelas, como regras de negócio complexas, mas isso não mudaria a didática do exemplo.



Então criamos uma VIEW para representar essa query no banco de dados. Podemos apagar e recriar essa query quantas vezes quisermos, para adicionar ou remover colunas, regras, dentre outros. Vamos usar o prefixo "view_" para facilitar a visualização desta entidade na base de dados. Veja que deixamos o filtro (p.cidade_id = 10) de fora, pois pretendemos usar esta VIEW para gerar relatório de títulos vencidos para diferentes cidades.



O próximo passo é definir uma classe (Active Record) que represente essa entidade do banco de dados para a aplicação. Usaremos o prefixo “View” para diferenciar objetos dessa classe dos demais objetos do modelo da aplicação. É importante salientar que não realizaremos operações como store() ou delete() neste objeto, por tratar-se de uma VIEW. Mas realizaremos carga de objetos (TRepository), por isso precisaremos declarar esta classe.



A partir do momento em que temos a classe definida, podemos utilizar os mecanismos padrão do framework para realizar a carga de objetos. E para carregar os objetos em memória, podemos simplesmente utilizar a classe TRepository, responsável por manipular coleções de objetos (Active Record). No exemplo a seguir, estamos carregando em memória os objetos que representam títulos vencidos com o valor superior à R$ 100, e somente da cidade cujo ID=10.



Para finalizar, podemos utilizar as classes padrão disponibilizadas pelo framework para criar os relatórios. O tutor já oferece um exemplo pronto de como gerar relatórios (www.adianti.com.br/framework_files/tutor/index.php?class=TabularRepo). Agora basta adaptar este exemplo para usar a View recém-criada.