Quando pela primeira vez coloquei as mãos em um código ASP.NET, usando a linguagem C# com banco de dados Firebird, eu tremi nas bases.

Primeiro pois NUNCA tinha mexido com esta tecnologia antes. Hoje posso até me considerar um fanboy do C# (mas não um CSharptard hehe :P).

O código da página era monstruoso, e todos os objetos de acesso a dados, regras de negócio e afins estavam codificados na interface de usuário.

Utilizando os componentes data-aware e fazendo as ligações segundo o método “empurrador de mouse” do Visual Studio 2003? Que isso, TUDO, era feito via código.

Tinha uma classe que “abstraía” certas atividades relacionadas ao banco de dados, mas mesmo assim todo o código é engessado na interface de usuário.

Quando fiz meu primeiro programa em ASP.NET do zero, após ter feito um curso, já pensei logo de cara em fazer o projeto em mais de uma camada: separar regras de negócio, componentes de acesso a dados e camada de apresentação em coisas distintas, sendo regras de negócio e componentes de acesso a dados mantendo um acoplamento um pouco mais forte (Classe de Conexão e derivadas!).

Acompanhem o raciocínio sobre as duas abordagens: fazer tudo dentro da UI e fora:

Quando fazemos tudo dentro da UI, com um forte acoplamento entre objetos de acesso (providers) de banco de dados, regras de negócio e camada de apresentação, nosso código fica fortemente engessado, ou seja, ele somente serve para aquela página e mais nada praticamente.

Com isso, um código que serviria para outra página, teria que ser reescrito, ou seja, temos um baixo reaproveitamento de regras de negócio que são utilizadas em N lugares de um sistema.

E consequentemente, a manutenção fica mais difícil: Uma alteração de uma regra de negócio que é utilizada em N lugares demandaria alteração nas N áreas do sistema em que ela é aplicada.

Falei apenas de regras de negócio: Agora veja a situação: E em uma migração do SGBD? Todos aqueles providers de acesso a dados que utilizamos podem não servir para outro SGBD, ou seja, teríamos que reescrever boa parte do sistema somente para alterar algumas classes!

Com o desenvolvimento em multicamadas, temos uma maior flexibilidade com o nosso código: podemos escrever um código, somente para teste, por exemplo, que não implicará em retrabalho na interface de usuário.

Este mesmo código poderá ser utilizado com várias interfaces de usuário: Interface Web, Desktop, Webservice, Serviço, entre outras, que pode ou não ter intervenção do usuário.

Veja, por exemplo, os artigos sobre o Controle de Acesso em ASP.NET: a interface de cadastro foi feita separadamente da camada de persistência e regras de negócio. Interface de cadastro esta que foi construída em ASP.NET, e no final da série de artigos utilizamos a mesma classe, sem alterações, em uma aplicação Windows Forms sem traumas.

Isto é proporcionado pelo alto reaproveitamento de código que é inerente a esta abordagem de desenvolvimento.

Com isso, caso tenhamos que dar manutenção em uma regra de negócio, esta regra é alterada nesta camada e ela é aplicada nos sistemas, sendo que todas as interfaces que implementam-a já sentirão os efeitos da alteração.

Ou seja, a manutenção ficou bem mais simples.

Então, concluíndo, caso você tenha que planejar um sistema todo do zero, opte pelo multicamadas. Não caia na tentação de fazer tudo na tela, baseado no clique-clique, com componentes data-aware, a não ser que seja estritamente necessário (Relatórios, alguém?).

O ganho de tempo lá na frente, quando o sistema crescer e demandar novas necessidades, vai compensar bastante.

Um abraço!