Camada de dados e de negócio

VB.NET 2005 - Camada de acesso a dados, de negócio e de apresentação I

Muito tem se falado em camada de dados , camada de negócio e camada de acesso a dados. Creio que a discussão seja salutar pois sempre leva a um enriquecimento do conhecimento , afinal ninguém sabe tudo , não é mesmo ?

Este artigo procura colocar de uma forma bem didática os conceitos de camada acesso a dados , camada de negócio e camada de apresentação. Você pode encontrar esse assunto na literatura como Camada de Dados ( Data Layer ) , Regras de Negócio ( Busines Layer) e Interface ( Interface Layer ).

Não é o meu primeiro artigo sobre o assunto, e, se você quiser conferir, veja os links abaixo:

O artigo será desenvolvimento usando as ferramentas Visual Basic 2005 Express Edition , SQL Server 2005 Express.

Primeiro estágio: E era tudo interface (o programador OCB)

Creio que todos nós já passamos , e , quem esta começando também vai passar pelo estágio do programador OCB. Neste estágio tudo se resume a interface ao banco de dados. Uma representação esquemática deste , vamos dizer, 'modelo' seria algo parecido com a figura a seguir:

Modelo usando uma única camada

A acróstico OCB quer dizer one-click-button , e significa aquele programador que põe um botão no formulário e no seu evento Click (o evento Load também é muito usado nesta técnica) coloca centenas de linhas de código que procuram fazer praticamente tudo da funcionalidade implementada no formulário: obter string de conexão, abrir conexão , acessar o banco de dados , criar objetos de acesso a dados , preencher os controles de formulário , e assim por diante...

Começar usando o técnica OCB não é demérito para ninguém, continuar a usá-la ao longo dos anos sim.

Um exemplo desta técnica muito usada é mostrado no código abaixo que preenche um controle ComboBox - cboClientes - com os dados de uma tabela chamada Clientes de um banco de dados SQL Server 2005:

O código esta resumido pois quem usa a técnica OCB geralmente consegue fazer muito mais que preencher uma combo, realizando ainda tarefas como : alterar, incluir e excluir dados.

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

'define um objeto dataset

Dim dsClientes As New DataSet

'obtem a string de conexao do banco de dados

Dim strconn As String = My.Settings.MacorattiConnectionString

Try

' para conectar com uma base de dados SQl Server usamos a classe SqlConnection

Dim clientesConn As New SqlConnection(strconn)

' o SqlDataAdapter é usado para preencher o DataSet com a instrução SQL

Dim clienteAdapter As New SqlDataAdapter("SELECT * FROM Clientes", clientesConn)

' Preenche o DataSet com os dados da tabela clientes

' Como podemos varios result sets em um DataSet

' damos o nome para o nosso de "Clientes".

clienteAdapter.Fill(dsClientes, "Clientes")

Catch exc As Exception

MsgBox(exc.Message)

Exit Sub

End Try

'preenche o combobox com os dados do dataset exibindo o nome

'e usando o codigo do cliente como referencia

With cboClientes

.DataSource = dsClientes.Tables("Clientes")

.DisplayMember = "nome"

.ValueMember = "clienteID"

End With

'seleciona o primeiro cliente

cboClientes.SelectedIndex = 0

End Sub

O erro que se comete neste caso é juntar tudo na camada de apresentação, pode parecer mais fácil de codificar , afinal , "tudo esta em um único lugar" mas vejamos os efeitos colaterais indesejáveis e que seriam os motivos para fazer com que o programador abandone a técnica OCB e evolua.

O exemplo acima é de apenas um formulário com apenas uma funcionalidade, imagine centenas de formulários implementando diversas funcionalidades...
- O código ficaria gigantesco e difícil de manter;
- O tempo de carga do formulário seria proporcional as tarefas realizadas, geralmente demoraria mais do que o desejado;
O acesso a dados feito diretamente na camada de apresentação engessa a aplicação tornando-a pouca portátil, assim , se for preciso migrar para outro banco de dados todos os formulários teriam que ter o seu código alterado;
O código usado na aplicação dificilmente poderia ser reutilizado, mesmo para aplicações parecidas, pois esta 'misturado' no formulário;
A implementação de uma nova funcionalidade implicaria em ter que se alterar toda a aplicação com todas as consequências de erros que isso poderia acarretar;(lei de murphy)
A segurança estaria comprometida visto que como toda inteligência do negócio e de acesso aos dados esta na interface a aplicação estaria instalada no cliente com todos os recursos disponíveis mesmo aqueles que o cliente não utilizaria;
Como o código esta todo concentrado na interface e possui funcionalidades de acesso a dados , negócio e interface a manutenção teria que ser feita por uma pessoa que conhecesse muito bem todas as áreas envolvidas e isso geralmente não ocorre; (Geralmente programadores odeiam programação de interface...)

Agora, não vamos radicalizar , não é mesmo, se você quer apenas 'brincar' com o código e criar programas que somente você vai usar e manter , ai então tem a desculpa de poder usar a técnica OCB , mas lembre-se da máxima - 'quando eu estou escrevendo código, eu e Deus somos capaz de entender o que esta sendo escrito , duas semanas depois , só Deus é capaz de entender...".

O feitiço pode virar conta o feiticeiro e após algum nem mesmo você pode entender o que foi feito...

Para os que , após lerem este texto se decidiram em continuar a usar a técnica OCB alguns conselhos finais:

Nada é tão simples como parece;
Antes de sair fazendo algo , planeje.

Se você ainda esta em dúvida e deseja alguns motivos para ajudá-lo a se decidir veja a seguir:

O desenvolvimento em camadas independentes permite que alterações possam ser feitas sem grandes impactos em todo o sistema.
Assim se você decidir trocar o seu SGBD , migrar entre bancos de dados diferentes, introduzir web services vai precisar somente na camada de acesso a dados;
Se você resolver trocar toda a sua interface somente a camada de interface sofrerá alterações;
Se alguma regra de negócio mudar , ou novas funcionalidades forem introduzidas, somente a camada de negócio será afetada.
Se houver a necessidade de se alterar as três camadas , você pode ter equipes diferentes, especializadas em cada camada , trabalhando de forma
independente;
A segurança pode ser isolada em camadas diferentes com diferentes restrições de acesso, facilitando o controle.

Agora eu vou mostrar uma aplicação usando a técnica OCB que ao longo dos artigos seguintes será aperfeiçoada até termos as camadas totalmente separada e o código otimizado com as técnicas de programação orientada a objeto. Afinal mostrando como não se deve fazer e uma das formas de ensinar a forma correta de realizar uma tarefa. Vamos lá...

Para tornar mais didática a leitura dos artigos e facilitar o entendimento vou usar uma aplicação bem simples como modelo a ser explorado. Será um cadastro de Produtos com duas tabelas: Produtos e Categorias.

Eu vou usar o banco de dados SQL Server 2005 Express , pois ele é grátis e bem melhor que o Access que precisa de uma licença. Se você não têm o SQL Server Express instalado , faça o download aqui : SQL Server 2005 Express Starter Kits

Para saber mais sobre as versões Express veja o também,

Cadastro de Produtos usando uma única camada

A primeira tarefa será criar o banco de dados e a as tabelas Produtos e Categorias, como não é o foco deste artigo mostrar como criar banco de dados e tabelas , se você não sabe como fazer isso , leia o meu artigo: VB.NET 2005 - Criando a base de dados, as tabelas e os relacionamentos no VB2005.

O nome do banco de dados usado neste artigo será Macoratti.mdf e a estrutura das tabelas Produtos e Categorias é a seguinte:

A tabela Produtos possui a coluna produtoID como chave primária e definida como identity

A tabela Categorias possui a coluna categoriaID como chave primária e definida como identity.

A tabela Produtos esta relacionada com a tabela Categorias pela chave categoriaID.

Tabela Produtos

Tabela Categorias

Abaixo temos a figura mostrando o relacionamento entre as tabelas criado no DataBase Diagrams:

Nota: Após criar as tabelas inclua alguns dados diretamente em cada tabela para que possamos usar nos exemplos.

Agora inicie o Visual Basic 2005 Express e crie um novo projeto do tipo Windows Application com o nome DAL_Net. (Opção File-> New Project)

Altere o nome do formulário form1.vb para frmProdutos.vb e vamos usar os assistentes para criar o nosso Cadastro de Produtos.

No menu Data clique em Add New Data Source e selecione a opção DataBase clicando no botão Next> ;

Clique no botão New Connection , e a seguir no botão Browse , selecionando o banco de dados Macoratti.mdf que foi criado na aplicação;

Selecione a tabela Produtos e Categorias , aceitando o nome MacorattiDataSet para a fonte de dados e clique no botão Finish.

Será criado o data source MacorattiDataSet.xsd contendo as tabelas selecionadas conforme a figura abaixo:

Agora volte para o formulário frmCadastros e exiba a janela Data Sources (No menu Data->Show Data Sources);

Em Data Sources selecione Produtos e altere o tipo para Details e em seguida arraste e solte no formulário. Serão criados os objetos ProdutosBindingSource, ProdutosTableAdapter e ProdutosBindingNavigator e toda a estrutura para navegar e manter a tabela Produtos será criada no formulário conforme figura a seguir;

Embora , essa não seja exatamente uma estrutura com uma única camada (O TableAdapter funciona como uma camada entre o banco de dados) , resolvi usá-la pela rapidez e pelo resultado final onde temos o cadastro de produtos pronto para uso.

Se olharmos o código gerado iremos ver o seguinte resultado:

Private Sub ProdutosBindingNavigatorSaveItem_Click(ByVal sender As System.Object, ByVal e As System.EventArgs)

Me.Validate()

Me.ProdutosBindingSource.EndEdit()

Me.ProdutosTableAdapter.Update(Me.MacorattiDataSet.Produtos)

End Sub

Private Sub frmProdutos_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

'TODO: This line of code loads data into the 'MacorattiDataSet.Produtos' table. You can move, or remove it, as needed.

Me.ProdutosTableAdapter.Fill(Me.MacorattiDataSet.Produtos)

End Sub

Agora eu vou fazer alguns questionamentos sobre o código gerado :

Cadê a validação dos dados ?
O método Fill esta carregando todos os registros da tabela no formulário. E se a tabela tiver 1.000.000 registros como ficaria o desempenho da sua aplicação ? (Embora você possa alterar a consulta no TableAdapter ele esta na interface da aplicação.)
A mudança ou migração para outro banco de dados ou qualquer alteração na interface vai impactar toda a aplicação;

Conclusão: "Por fora bela viola , por dentro pão bolorento." , os assistentes fazem todo o trabalho para você mas isso tem um preço : você não tem total controle sobre o código gerado e qualquer alteração poderá se tornar um pesadelo.

Definitivamente este modelo pode até ser bom para protótipos simples mas fere o principio da portabilidade e escalabilidade da qualidade de software.

Vamos ter que mudar tudo incluindo uma camada de acesso a dados. Fazendo isso veremos como ganhamos mais flexibilidade e facilidade para efetuar mudanças no projeto de software.

Para acompanhar como criar uma aplicação em camadas acompanhe os artigos dos links abaixo e compare com a aplicação criada acima sem usar as boas práticas:

Até o próximo artigo VB.NET

José Carlos Macoratti

C# - Criando uma aplicação em 3 camadas

ASP.NET - Trabalhando em camadas