Olá pessoal, gostaria de mostrar com este artigo como organizar o código reaproveitando métodos, funções e tudo mais. Separar em projetos, usar DAO, DTO e BRL. Nunca faça tudo direto no código desorganizado; o sistema vai acabar aumentando e precisando de muita alteração no caso da falta de organização.

 

Referência:

- Ferramenta de desenvolvimento Visual Studio.NET 2008 ou superior;

- Linguagem C#, VB.NET ou J# (essa organização pode ser feita em qualquer linguagem dentro da ferramenta);

 

Breve explicação

 

         Não vou mostrar muito código com este artigo, vou mostrar apenas uma organização legal para desenvolvimento de software e reaproveitamento. O primeiro exemplo que vou comentar é sobre desenvolver um sistema do tipo Web. A parte do layout sempre vai acessar a parte de negócio e o negócio sempre acessa a camada de dados. Nunca o layout poderá acessar diretamente a camada de dados.

         Layout significa arquivo .aspx, .asmx, .js, .css, .vb, .html, e outros. Isso tudo é layout do sistema. O mesmo nunca deve ter regra de negócio, a regra deve ser feita dentro da BRL. Não confunda regra de tela com regra de negócio, a regra de tela pode ser feita de várias formas e jeitos.

         A regra de negócio sempre acessa a camada de dados, método sem regra de negócio faz apenas um chamada; caso contrário, executa a regra de negócio e depois acessa a camada de dados.

         A camada de dados apenas acessa os dados, não importa que tipo seja a base, SqlServer, Oracle, MySql, SQL Mobile, Acess, Sybase, Txt, XML ou outros. A função da camada de dados é apenas, inserir, excluir, atualizar e buscar os dados da base seja qual for.

         O envio e recebimento de parâmetro usando DTO (uma classe cheia de propriedades get e set) é no meu ponto de vista a melhor forma, dependendo do caso. Utilizo para passar como parâmetro de entrada. Você pode escolher também para enviar e receber; o melhor mesmo é enviar um DTO e receber outro DTO. Muitas vezes, já que não tem integração com outra linguagem como Java, retorno DataTable, DataSet que é um tipo de dados do C#.NET; depende muito do sistema.

 

Na Prática

 

         Na criação do projeto Web, gerei primeiro o nome e depois coloquei .Web. Por exemplo: NomeDoProjeto.Web. Esse foi o nome do projeto, isto é, do arquivo .csproj ou .vbproj. Automaticamente esse é o mesmo nome do namespace. Tenho apenas os arquivos de layout. (Imagem 1)

 

Imagem 1

 

         Note que, nesse projeto tenho apenas os arquivos .aspx, .master, .js, .css, .skin, imagens e tudo mais. Depois de criar esse projeto, criei outro chamado Business. Lembrando que isso é só uma sugestão para organização de código.

         Na próxima imagem (imagem 2), mostra o código Business.

 

Imagem 2

 

         Dentro da mesma solução, criei um projeto com o mesmo nome, porém referenciando o Business. Por exemplo: NomeDoProjeto.Web.Business. Na imagem 2, mostro as pastas BRL, DAO, DTO, LINQObjects e outros. O importante para este artigo são as pastas BRL, DAO e DTO.

         Ao abrir cada pasta, existem apenas arquivos com o final igual ao respectivo nome da pasta, por exemplo: PassadaDAO.cs, PassadaBRL.cs, PassadaDTO.cs.

 

Imagem 3

 

         Toda BRL recebe como parâmetro a DTO e acessa a classe DAO. É um padrão seguido para organização do código. A regra de negócio fica dentro da BRL, caso necessite da mesma. No caso de não ter regra, chamo o método da classe DAO e retorna, fica como se fosse um transportador. Code 1.1

 

public void IncluirArquivo(Arquivo arquivo)         {             this._arquivoDAO.IncluirArquivo(arquivo);         }

Code 1.1

 

         O code 1.1 mostra a DAO sendo chamada e acessando o método IncluirArquivo passando a classe Arquivo como parâmetro.

 

public partial class Arquivo     {         public DateTime DataMovimento { get; set; }     }

Code 1.2

         A classe Arquivo tem uma propriedade com get e set chamada DataMovimento e do tipo DateTime. As classes DAO sempre vão estender de outra classe responsável pela conexão com o banco de dados. No meu caso, chamei-a de BaseDAO.cs. (Imagem 4)

 

Imagem 4

         Outro segredo que uso também dentro das classes DAO é o internal classe em vez de ser public. Code 1.3.

 

internal DataTable PesquisaPoloCaptura(Passada passada)         {             StringBuilder query = new StringBuilder();             query.Append(" SELECT...

Code 1.3

 

         Segue acima, a metade de um método da DAO.

         Dentro da BRL, faço apenas uma instância e utilizo o método que preciso. Pode ser usado também, um public interface, que possui apenas a assinatura do método. Para não aumentar muito o artigo, segue um link falando um pouco mais sobre public interface (http://www.aspneti.com/usando+public+interface+677,0.aspx).

         Tendo organizado as classes e o projeto dessa maneira mostrada; posso utilizar WebService. A interface é o arquivo .asmx e acessa a BRL que acessa a DAO. Fica tudo em um projeto Business que pode ser aproveitado.

         Muitas pessoas utilizam vários projetos dentro de uma mesma solução, no meu ponto de vista, fica mais difícil e complicado quando se trabalha em equipe gerenciar esse tipo de coisa. Fora as referências em vários projetos.

         Se eu quiser utilizar ou reaproveitar o projeto Business em um projeto do tipo WindowsForm, fica muito fácil e rápido. O que muda no final é apenas o layout para o cliente, ou seja, a camada fica separada.

 

Bom, eu fico por aqui; sou o Mauricio Junior.

Qualquer dúvida, entrar em contato pelo site.