A falácia do desenvolvimento em 3 camadas

O desenvolvimento em 3 camadas, pedido em tantas vagas de emprego, em projetos de software, tanto discutido e difundido em fórums, livros e revistas de TI é uma verdadeira falácia!

falácia1
fa.lá.cia1
sf (lat fallacia) 1 Qualidade de falaz. 2 Engano, logro, burla. 3 Sofisma.

sofisma
so.fis.ma
sm (gr sóphisma) 1 Lóg Raciocínio capcioso, feito com intenção de enganar. 2 Argumento ou raciocínio falso, com alguma aparência de verdade. 3 pop Dolo, engano, logro.

Antes de começarmos a codificar alguma coisa, é bom um pouco de história para nos situarmos ! O termo foi difundindo erradamente. Vamos começar do começo e por partes, ou camadas , se preferir. 😛

Tive um primeiro contato com o termo desenvolvimento em camadas por volta do ano 2000. Na época, uma das linguagens mais usadas era o Visual Basic 6.0, o Java estava crescendo, e o Delphi era bem usado. A Microsoft recomendava o uso de ADO, presente no pacote MDAC, em detrimento ao DAO. O objetivo era ir no banco o mais tarde possível, pegar os dados e fechar a conexão o mais cedo possível. Surgiu então o Win DNA (Windows Distributed interNet Applications Architecture), como o link diz é um nome marketeiro para tecnologias que já existiam mas foram agrupadas em uma arquitetura (COM, COM+, antigo MTS; ADO, ActiveX, ASP). Na época a minha bíblia era o livro Mary Kirtland, posteriormente li também o livro do Fábio Câmara.

A arquitetura Win DNA

A MS,  então,  comecou a divulgar a divisão de responsabilidades. A maioria dos programadores VB na época não usava nem o conceito de Classe, isso passou a ser mais demonstrado nos exemplos e no próprio livro, mas como o VB não era verdadeiramente OO não surtiu muito efeito. Até mesmo a divisão em DLL’s não era comum, o que mais se via eram executáveis gigantescos ou vários gigantescos por módulo!

O acesso aos dados era feito usando-se o RecordSet do ADO, criava-se um, ia no banco de dados, populava ele, fechava-se a conexão e usava na aplicação. A arquitetura,  então, era os Formulários (Form) no EXE e DLL’s;  A escrita do CRUD ficava em uma DLL. Na época,  a MS incentivava o uso massivo de Stored Procedures. E começou um movimento para tirar a lógica de negócios da camada de apresentação, ainda na fase dessa arquitetura era muito comum ter regras no banco de dados, mas falava-se em colocar essas regras em DLL’s também, então a camada de apresentação chamava uma DLL que continha algumas regras, que chamava a DLL de CRUD, que populava um RecordSet e retornava pela cadeia até a tela do usuário.

As coisas mudam no .Net

Com a vinda do .Net tivemos uma migração de algumas aplicações de maneira automática por meio de Wizards, alguns programadores também começaram a programar em VB.Net ou foram para o C#, uma linguagem mais de “gente grande” por ser mais parecida com Java. Porém,  o paradigma é diferente! VB 6.0 não é puramente OO, VB.Net sim! Aliás, o VB.Net é somente a sintaxe do VB 6.0, ele é uma linguagem em cima de outra plataforma.

Mas as pessoas são acostumadas a hábitos e,  o desenvolvimento em .Net foi feito da mesma maneira que vinha sendo feito no VB 6.0: lógica separada dos dados.

O paradigma OO nos diz: Cada classe determina o comportamento (definido nos métodos) e estados possíveis (atributos) de seus objetos, assim como o relacionamento com outros objetos. (fonte: Wikipedia)

Na arquitetura Win DNA os dados ficavam em um RecordSet e o comportamento em funções de uma classe em uma DLL, o RecordSet passeava pela aplicação e,  se ela fosse um controle de Estoque uma função recebia o RecordSet, percorria ele para ver se algum item estava zerado para gerar um novo pedido.

Na arquitetura OO não existe essa separação, o que eu quero mostrar com os próximos posts é que ao termos objetos de domínio, estamos facilitando o desenvolvimento por deixarmos tudo agrupado (comportamento + estado), a facilidade de manutenção será muito maior. Outra coisa, o uso de DataSet’s deixa o código também mais confuso, usando classes POCO o código será muito mais fácil de entender e leve.

Continue acompanhando!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.