Visual Studio + NHibernate: Construindo aplicações em camadas – (cont. V)

No post anterior desta série discutimos sobre a criação da camada DAO. Geramos as classes e interfaces, além de preparar um DAOFactory que é o caminho por onde serão feitos acessos às funcionalidades dos DAO´s. Vimos também como utilizar uma classe abstrata BaseDAO que, combinada com o MyGeneration, pode facilitar bastante no uso dos recursos do Hibernate.

Neste post vamos discutir sobre a camada de regras de negócio (BO). Vamos acessar os DAO´s através de um DAOAccess e criar um BOFactory para que a camada de apresentação possa utilizar este caminho para fazer acessos ou requisições às regras de negócio.

Como o próprio nome já diz a camada de regras de negócio define as regras ou comportamentos que a aplicação terá durante o processamento de requisições oriundas da camada de apresentação. Esta camada pode ser formada por uma ou várias classes que serão responsáveis por controlar a entrada e saída de informações. Não acho legal criar uma única classe para controlar todas as regras de negócio da aplicação. Procuro agrupar em classes, separando as operações relacionadas. Dessa forma consigo ter melhor visão dos módulos da aplicação.

Mas o que tem numa classe de negócio?! Como sabemos uma classe é formada basicamente por métodos e propriedades. Os métodos irão ser chamados na camada de apresentação para realizar as operações de negócio. As porpriedades irão formar parâmetros de entrada ou saída da classe para determinar algum comportamento do método. Vamos conhecer algumas métodos e propriedades que podemos colocar numa classe de negócio:

1. Inclusão e alteração de dados. Esses métodos são os mais comuns em qualquer aplicação que utilize banco de dados. Eles serão chamados pela camada de apresentação para realizar a devida operação no banco de dados (através dos DAO´s); Nesses métodos podemos encontrar procedimentos comuns em operações de inclusões e alterações. E, por exemplo:
   • validação de permissões de usuário;
   • validação de campos;
   • verificações de relacionamentos entre tabelas do banco;
   • verificações de violação de índices ou chaves;
   • abertura e fechamento de transações;
   • inserções e/ou alterações em tabelas;
   • outros processos durante a operação.
2. Exclusões. Esses métodos realizam operações de exclusão de dados do banco. Internamente também possui procedimentos comuns ao processo:
   • validação de permissões;
   • verificação de violação de relacionamentos;
   • verificações de violação de índices ou chaves;
   • abertura e fechamento de transações;
   • eliminações de dados em tabelas
   • outros processos durante a operação.
3. Seleções de linhas da tabela. Esses métodos vão dar suporte a consultas e listagens que a camada de apresentação possa necessitar e também para outros objetos de negócio:
   • Seleção de uma linha da tabela por chave primária ou índice único;
   • Listagem de registros das tabelas controlada ou não por filtro;

Acredito que, no mínimo, todas as aplicações realizam alguma ou todas as operações e sub-processos citados acima. Já que esses processos são comuns a maioria das aplicações em camadas e que fazem acesso a banco de dados, seria interessante que pudessemos automatizar a criação desses métodos. Foi exatamente o que eu fiz criando scripts no MyGeneration. Vamos utilizá-lo para gerar as classes da nossa camada de negócio.

Os scripts que deverão ser utilizados neste processo são:

• BO Interface for Nhibernate.csgen que irá gerar as interfaces das classes de negócio;
• BO Class for Nhibernate.csgen que irá gerar as classes de negócio, com as funcionalidades principais já implementadas.

Claro que, obedecendo a hierarquia em camadas, as classes de negócio fazem chamadas às classes DAO´s. E essas chamadas são feitas atravéz do DAOFactory por um DAOAccess. Parece complicado mas não é. Apenas estou determinando que nenhuma classe DAO seja instanciada com new diretamente na camada de negócio. Quem terá essa responsabilidade será o DAOAccess e quem irá responder a essas solicitações de instanciamento dos objetos é o DAOFactory.

Acho que não preciso mais comentar sobre o processo de criação dos BO´s e das interfaces no MyGeneration. Inclusive sei que alguns leitores já se adiantaram e geraram essas classes por conta própria, através de nossa explicação anterior. Só irei fazer alguns comentários sobre este processo:

1. As intefaces devem ser geradas na pasta BO da biblioteca AgendaTelefonica.Interface.
2. Os BO´s devem ser gerados na pasta da biblioteca AgendaTelefonica.BO.
3. No Visual Studio, após ter sido gerado os arquivos, selecione as classes e, clicando com o botão direito do mouse em algum dos arquivos selecionados, selecione a opção “Include In Project“. Isso deve ser feito em cada biblioteca onde os arquivos foram gerados.
4. Após a realização dos procedimentos o Solution Explorer estará assim:

É importante conhecer o conteúdo dos arquivos gerados e entender seu funcionamento. Destaque para os arquivos

• DAOAccess.cs, que se comunica com a camada DAO através do DAOFactory.cs;
• BOFactory.cs que será a via de comunicação entre a camada de apresentação e a regra de negócio.
• IBOFactory.cs que é a interface de exposição do BOFactory.cs

Aproveite e olhe a estrutura dos arquivos BO´s gerados, por exemplo CidadeBO.cs. Veja que nele e em todos os outros BO´s existe uma estrutura inicial com aquelas funcionalidades principais e comuns a todos os arquivos de regra de negócio (valiação, inserção, exclusão, etc.).  Note também que no construtor do BO existe a ligação com o DAO correspondente e todos os métodos fazem uso desta instãncia do DAO.

Não é necessário ter um BO para cada DAO correspondente. Voce pode agrupá-los em funcionalidades próximas na sua aplicação, criando assim uma visão de módulo. Por exemplo, voce pode embutir num único BO as funcionalidades para controlar endereços. Neste BO irá conter todos os métodos para gerenciar endereços: UF, Cidade, CEP, etc.  Assim, na camada de apresentação, voce pode fazer uso de um certo EnderecoBO e nele já possuir tudo que se precisa pra controle de endereço: seleções, inclusões, alterações, etc. de Uf’s, cidades, ceps, etc’s. Inclusive está é a atitude mais comum no que diz respeito a criação de BO’s.

Certamente durante o desenvolvimento da camada de apresentação será necessário criar vários novos métodos para operações de seleção de dados e/ou persistência, tanto nos DAO’s quanto nos BO’s. Paralelamente, alterações nas respectivas interfaces também serão necessárias. Tudo para que os BO’s realizem com exatidão seu papel de controlar a regra do negócio. Montamos o esqueleto principal que dará suporte a aplicação. No próximo e último post estaremos criando o projeto do site para camada de apresentação. Vamos criar uma tela que servirá de base para entendimento do processo e criação das outras. Vamos criar também novos métodos em alguns DAO´s e BO´s para mostrar um pouco do potencial do Hibernate nesta questão.

Fiquem a vontade para comentar. Espero que estejam gostando e até o próximo!

Correções nos Scripts e Bibliotecas

Para aqueles que fizeram download dos scripts no post sobre desenvolvimento ágil e/ou nas bibliotecas na parte IV do tutorial sobre Visual Studio + NHiberante; existiam alguns bugs que foram corrigidos. Os novos arquivos substituiram os antigos nas referidas páginas.

Os scritps geradores de página .ASPX tiveram correções nas validações de campos. Nas bibliotecas, a classe BaseDAO tinha um problema de configuração do NHibernate. Como eu, até então, só estava usando no servidor de aplicação não tinha detectado este problema. No momento que eu precisei utilizar num programa sem servidor de aplicação, diretamente no IIS, o problema foi detectado e corrigido.

Aproveito para citar que nos próximos dias estaremos dando continuidade ao estudo sobre Visual Studio + NHibernate e essas novas correções serão necessárias.

É isso.