O NeoMatrix Tech está de casa nova!

Você deverá ser redirecionado em 6 segundos. Se não, visite:
http://www.leonelfraga.com/neomatrixtech
e atualize seus favoritos.

Aviso IMPORTANTÍSSIMO!

Aviso aos navegantes:

O NeoMatrix Tech mudou de casa!!!

A partir de agora, acessem pelo novo endereço:

http://www.leonelfraga.com/neomatrixtech

Ué... mas é só o domínio mudou de lugar?

R: Na verdade, não é bem assim hehe. Este domínio que você acessa agora aponta para um blog hospedado no Blogger, enquanto no novo, aponta para um blog na plataforma Wordpress, hospedagem própria, muito mais rápida e com um layout mais agradável de ler ;)

Não vou fechar este domínio igual ao que eu fiz com o NM Light (que já está 100% na nova plataforma). Talvez beeeeeeem depois eu faça isso.

Todos os posts daqui se encontram lá, e novos posts serão colocados somente no novo endereço.
A única coisa que não consegui importar foram os comentários. Mas em breve vai ter um post contando sobre a epopéia que foi migrar o NeoMatrix Tech!

Somente vou fechar a área de comentários daqui. Caso queiram comentar, favor ver o post correspondente no "Novo NeoMatrix Tech" e comentem por lá. É bem melhor! (pena que os permalinks "amigáveis para SEO" não funcionam lá, dá erro 404 e não consigo fazer a configuração funcionar. E olha que eu já vi vários artigos falando desse assunto :( ).

Quem assina o feed, já está lendo o conteúdo do novo NeoMatrix Tech!

sábado, 23 de maio de 2009

Objetos de acesso a dados e Regras de negócio: Direto na UI ou separar?

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:

Multicamadas ou Camada Única?

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!

0 comentários:


Postar um comentário

Para tornar este artigo ainda mais interessante, escreva suas críticas (desde que construtivas e sem ofenças), elogios, sugestões, complementos, dúvidas, etc, etc, etc!!!

  © Blogger templates ProBlogger Template by Ourblogtemplates.com 2008 - Editado e configurado por Leonel F.

Voltar ao TOPO