Artigo Clube Delphi Magazine 98 - POO e Multicamadas

Nesse artigo veremos

·                         Criação de uma aplicação modelo com ASP.NET 2.0, AJAX e POO;

·                         Divisão da aplicação em camadas;

·                         Criação de camadas DAL, BLL e de uma DTO;

·                         Transferência de objetos entre camadas;

·                Separação da lógica de negócio e acesso a dados da interface da aplicação.

Qual a finalidade

·                Criar aplicações mais robustas, fáceis de manter, ao mesmo tempo que utiliza boas práticas de desenvolvimento.

Quais situações utilizam esses recursos?

·                Na opinião do autor, todos os WebSites deveriam ser desenvolvidos dessa forma;

Na arquitetura de uma aplicação ASP.NET tradicional, normalmente utilizamos um banco de dados relacional e criamos uma interface com controles data-bound. Com os novos controles de acesso a dados introduzidos pelo ASP.NET 2.0, podemos utilizar um SqlDataSource ou dbxDataSource, por exemplo, para conectar a um banco de dados e manipular informações em tela.

Mas será que essa é a melhor forma de desenvolver aplicações ASP.NET? Será que é a maneira correta? Não é estranho ter funcionalidades de acesso a dados combinadas com controles de UI? E a POO, como tirar do papel e colocar em prática? É muito comum um desenvolvedor, pela pressão em finalizar logo um projeto ou mesmo por falta de conhecimento, sair colocando código SQL no próprio Web Form. E essa com certeza não é uma boa prática.

O objetivo deste artigo é ensinar você leitor a aplicar boas práticas de desenvolvimento de aplicações ASP.NET. Você aprenderá, através de um exemplo prático passo a passo, como construir uma solução Web utilizando boas práticas de desenvolvimento.

O que vamos desenvolver é uma aplicação distribuída em camadas, utilizando o melhor do que a POO (Programação Orientada a Objetos) tem a oferecer. Podemos dizer que nossa solução será praticamente 100% Orientada a Objetos.

A metodologia que utilizarei é simples, porém interessante. Iniciaremos criando uma aplicação da forma tradicional, com código de acesso a dados mesclado com o código de interface. A seguir, vamos começar a separar a aplicação em partes (camadas), incluindo código e funcionalidade em cada uma. O porquê de dividir em camadas é explicado a seguir.

Antes de iniciar, vou apresentar o nosso “mapa”. A Figura 1 representa a solução que vamos desenvolver. É importantíssimo que você entenda cada parte da aplicação multicamadas e as siglas utilizadas, pois elas serão referenciadas durante todo este tutorial.

Durante o desenvolvimento da solução, sempre que tiver uma dúvida em relação a qual camada estamos implementando, determinada funcionalidade, consulte essa figura.

Figura 1. Arquitetura da solução multicamadas

Explicando as camadas:

·                     Banco de Dados (DB): será um banco no SQL Server 2005 Express;

·                     Data Access Layer (DAL): é a camada que cuida e centraliza o acesso a dados. Aqui ficam os códigos para inserir e atualizar dados nas tabelas do banco e onde são utilizadas as classes do ADO.NET, ou seja, é a camada encarregada da persistência dos dados;

·                     Business Logic Layer (BLL): camada de regra de negócio, funciona como “ponte” entre a DAL e DB. Contém regras de negócio da aplicação, validações a nível de objeto etc.

·                     Presentation ou Interface: a aplicação ASP.NET propriamente dita. Note que podemos utilizar outro tipo de interface, como Windows Forms ou um dispositivo móvel (com o auxílio de um Web Service).

Por que desenvolver dessa forma (vantagens)

Muitos podem estar se perguntando: Por que eu devo desenvolver dessa forma e não da maneira como estou acostumado? Quais as reais vantagens que eu ganho? Vamos enumerar os principais benefícios:

·                     A camada de apresentação contém apenas código de UI, ela não acessa o banco de dados diretamente, não tem conhecimento sobre tabelas, esquemas, qual o tipo do banco de dados, apenas cuida de apresentar os dados para o usuário e manipulá-los. Com isso, podemos dizer que a aplicação cliente é thin-client (cliente leve). Isso nos dá um nível elevado de abstração;

·                     Independência de tipo de aplicação cliente: como o acesso a dados é centralizado, podemos compartilhar esse código de acesso entre vários tipos de aplicações cliente, como Web, Desktop e Mobile;

·                     Migração facilitada: Como estamos separando a solução em camadas, uma possível migração fica muito simples, já que tudo está separado. Por exemplo, se quisermos migrar de SQL Server para Oracle, apenas uma camada (a DAL) precisaria sofrer alguns ajustes, as outras camadas não enxergam esse acesso;

·                     Reaproveitamento de código: o código de acesso a dados (e BLL), por exemplo, não é replicado caso tenhamos vários tipos de aplicativos cliente ou caso tenhamos múltiplas interfaces fazendo uso dos mesmos objetos;

·                     Fácil substituição: para explicar a POO, muito recorre-se à vida real para fazer comparativos, vou fazer o mesmo aqui. Imagine um computador, ele é formado por vários objetos, como se fossem “camadas” que se comunicam. Se uma peça queimar ou você quiser fazer um upgrade, precisará trocar somente aquele objeto, e não o computador todo. O mesmo acontece em nossa solução. Se você desejar implementar um mecanismo mais robusto de acesso a dados, basta criar uma nova camada DAL e substituir na arquitetura, as demais partes permanecem inalteradas;

·                     Manutenção facilitada: como os aplicativos estão em camadas, se houver um erro ou for necessário fazer uma manutenção / correção, normalmente apenas uma camada é afetada, o que também facilita o deploy;

·                     E finalmente, estaremos usando o melhor da POO. Eu fico imaginando como não era trabalhoso e árduo trabalhar com o ASP clássico sem esses recursos (o include era o melhor recurso para “herança”!). Em nossa solução vamos usar e desfrutar de recursos da POO pura, como classes, herança, encapsulamento e muito mais, além de um novo e poderoso recurso do ASP.NET 2.0: o ObjectDataSource.

Explicados os fundamentos, arquitetura e vantagens da solução proposta, vamos para a prática.

  ...