Apêndice 1: Visual Studio + SQL Nativo: Construindo aplicações em camadas

Na série Visual Studio + NHibernate: Construindo aplicações em camadas ensinamos algumas técnicas de como utilizar o NHibernate e o Visual Studio na construção de sistemas em camadas. Idealizamos um projeto exemplo (Projeto AgendaTelefonica), modelamos a solução no Visual Studio e preparamos o ambiente para criação das classes. O programa RSClass – Gerador de classes foi largamente utilizado nesse processo. As classes do sistema foram geradas pelo RSClass que é um especialista neste assunto. As classes são geradas apartir das informações estruturais das tabelas do banco de dados (metadados). Ficou claro que o NHibernate deve estar presente apenas nas classes de acesso a dados (DAO). A biblioteca Regisoft contém classes abstratas que implementam as questões relacionadas ao NHibernate que tanto assustam os programadores: sessão, conexão, objetos transientes, objetos persistentes, cache, mapeamentos, etc.

Não é nenhuma novidade que o NHibernate diminui bastante o trabalho do programador nas questões relacionadas a persistência de dados. Este excelente framework possui algumas caracteristicas que atraem bastantes os desenvolvedores:

  • Independência de dados: com a utilização deste framework é possível alternar entre banco de dados com o mínimo de modificações no sistema. Leia mais…
  • Mudança de paradigma: os bancos de dados utilizam um paradigma relacional. Com o NHibernate há uma migração para o paradigma orientado a objetos. Assim as tabelas passam a ser vistas como lista de objetos e as linhas das tabelas passam a serem vistas como objetos. Os campos dos registros das tabelas passam a ser vistos como propriedades dos objetos. Os relacionamentos entre tabelas nas chaves estrangerias são vistos como agregações na orientação a objeto. O NHibernate é o responsável por essa conversão. Essa forma de visão do banco de dados dá bastante flexibilidade e produtividade ao programador.
  • Criteria e HQL: O NHibernate possui um dialeto próprio para recuperação de dados. Novamente a orientação a objetos é utilizada. O próprio NHibernate é responsável pela conversão do HQL/Critéria que é utilizado no paradigma orientado a objetos do NHibernate para o SQL no paradígima relacional que é o que os SGDB’s entende.

Essas são algumas das vantagens da utilização desse excelente framework. Mas nem tudo são flores. Essas e outras facilidades que NHibernate propõe tem um preço; como tudo na vida. Há quem não goste dessas facilidades. O principal motivo dessa oposição é o alto tráfego que o NHibernate gera com o banco de dados. E posso afirmar: a modelagem do banco de dados interfere bastante nesse problema. Dependendo da modelagem, normalização e número de relacionamentos a situação pode ficar muito ruim. Quase impratícável!!!! Mas, claro! Há como contornar esta situação. Há atitudes e planejamento na arquitetura do sistema que podem facilmente minimizar os efeitos do grande tráfego gerado. Depende muito da experência e sensibilidade do projetista. Isso até pode ser assunto de posts futuros. O fato é que o mesmo NHibernate que ajuda pode atrapalhar. Não é difícil encontrar quem desaconselhe o seu uso. Veja aqui um exemplo.

Então pra atender aos projetistas que não são a favor do NHiberante iremos tecer alguns comentários sobre como construir sistemas em camadas com Visual Studio SEM o NHibernate e utilizando o SQL Nativo. No NHibernate nós herdávamos da classe BaseDAO presente na biblioteca Regisoft. Fizemos isso na sequência de artigos citada acima. Lembrando que tudo do NHibernate era encapsulado nessa classe básica e todos os DAO’s da aplicação herdava dessa classe. A classe BaseDAO serviu de inspiração pra criação da nova classe abstrata chamada NativeDAO também presente na biblioteca Regisoft e que utilizará SQL nativo. Planejei e desenvolvi essa classe buscando aproveitar características importantes da classe irmã (BaseDAO). Muitos métodos da classe BaseDAO foram transcritos para a a classe NativeDAO utilizando SQL nativo.

Porém, surgem algumas questões na utilização desta nova classe e na consequente nova arquitetura:

  1. No NHibernate utilizavamos o paradigma orientado a objetos. Isso era conseguido utilizando um mapeamento das classes (.hbm.xml) com as tabelas do banco de dados. Qual será o paradigma do novo projeto? Simples. Paradigma relacional. Já que iremos utilizar o SQL Nativo nada mais natuaral que utilizemos o paradigma relacional. O mapeamento O/R dará lugar ao’s VO’s (Values Objects). Esses componentes serão autênticos DTO´s (Data Transfer Object). Não haverá nestes VO’s uma coisa interessante que tinhamos nos OR’s: a agregação. As propriedades dos VO’s serão tipos primitivos. Nos OR’s poderiamos ter outros objetos mapeados além dos tipos primitivos, fruto das chaves estrangeiras. Assim, esses VO’s serão apenas componentes para transferência de informações de uma camada para outra e contendo apenas os ID’s das chaves estrangérias. Não mais objetos.
  2. HQL e Criteria que utilizavamos no NHibernate darão lugar os bons SQL. A preferência é utilizar apenas SQL ANSI para tentar ao máximo não perder a independência de banco de dados. Nosso componente permite a utilização de Stored Procedures mas vamos evitar já que a sua reescrita em outro banco de dados pode dar muito trabalho. No máximo as Storeds Procedures poderão ser utilizadas em processos específicos. As Views poderão ser utilizadas já que não há muita dificuldade na criação caso seja necessário mudar de banco de dados. Uma outra coisa que deveremos utilizar nessa nova abordagem são as TRIGGERS. Porém com um único objetivo: nos bancos de dados que não possui campos de auto-incremento elas deverão ser utilizadas para gerar o ID (chave primária) na hora da inclusão de registro. Também será necessário adotar padrões na nomeclatura das tabelas, campos, etc. no banco. Clique aqui e veja a nossa proposta.
  3. A conexão com o banco de dados será gerenciado por outro componente: Regisoft.Data.DbFactory. Ele define vários recursos para criação de conexão e querys e pode ser utilizado com os seguintes bancos de dados: Firebird, MS SQL, MySQL, Oracle, PostgreSQL e SQLite. Para outros bancos de dados, nada impede de cada desenvolvedor modificar o fonte gerado pelo RSClass para utilização com outros bancos de dados. Isso é uma flexibilidade importante. Afinal assim o NativeDAO poderá ser utilizado com qualquer banco de dados do mercado. O único parâmetro que ele pede no construtor da classe é exatamente o componente de conexão que será utilizado (IDdConnection: FBConnection, SQLConnection, OracleConnection, etc.). Fica a critério do programador definir qual e como a conexão será utilizada.

Por fim duas perguntas: irá diminuir o tráfeto? A resposta pra essa pergunta é “depende”. Comparado ao NHibernate, certamente. Mas depende da qualidade das querys/selects que o programaador criar no sistema e da frequencia com que eles serão utilizados. A vantagem é que de um jeito ou de outro o programador saberá exatamente que momento uma query tá sendo utilizada e sua definição. Afinal ele mesmo que definiu. Por isso é importante que o programador planeje bem suas querys. O NativeDAO é apenas o meio por onde essas querys serão utilizadas. A segunda pergunta é: dá pra utilizar um servidor de aplicação? Claro que sim. A nossa arquitetura continuará a mesma. O que vai mudar é a forma de acesso aos dados. Por isso a arquitetura em camadas é interessante. A mudança em uma camada não deve impactar nas camadas acima. Dê uma olhada nesse post e nesse outro pra entender mais sobre o assunto.

Portanto, o excencial é planejar bem sua arquitetura e entender suas vantagens e limitações. Não existe a melhor ou pior. O que existe de fato é o que é melhor aplicado a cada situação encontrada. E, claro, o gosto e conveniência de quem desenvolve.

Anúncios