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.