Erick Sasse

Ontem trabalhei o dia todo em meu primeiro projeto real em ASP.NET. Adoraria ter utilizado o Delphi 8 para isso, mas um conhecido bug me impede de utilizá-lo no meu notebook. Minha esperança é que o Diamondback não venha com esse problema.

Bom, mas voltando ao projeto, os requisitos eram simples. Apenas incluir um sistema de notícias dinâmicas em um site já existente, algo bem parecido com um blog. Na página principal do site, o título das últimas notícias seriam listadas. Ao clicar no título, uma página com a notícia completa seria exibida. Além disso, precisaria existir uma área administrativa restrita onde o jornalista pudesse gerenciar as notícias.

Utilizei Visual Studio .NET 2003 e C#. Confesso que foi muito mais simples do que pensei. Achei que teria dificuldades em inserir código ASP.NET em páginas HTML já prontas e formatadas com tables, flash, e todas essas coisas que eu não gosto. Mas para converter uma página HTML em ASPX (extensão das páginas ASP.NET) bastava incluir a página no projeto do VS (Visual Studio) e renomear a extensão. O VS detecta que a página não tem uma classe derivada de WebForm e cria uma automaticamente para você.

Não tinha experiência com Visual Studio e nem C# além dos testes e treinamentos MSDN que realizei. Inicialmente pensei em tirar proveito de tudo que a IDE pudesse gerar automaticamente para mim, pois não podia investir muito tempo nesse projeto. Mas depois, percebi que não era uma boa, pois estava ficando com vários componentes duplicados entre as páginas e não estava gostando disso. Por exemplo, se você adotar o “método fácil”, arrastando para as páginas a tabela do banco de dados que você quer acessar, a IDE cria todos os componentes para acesso: OleDBConnection, etc. Então para cada página você teria todo o conjunto de objetos de conexão repetidos. Isso seria um inferno para manter. Decidi abandonar tudo e usar uma abordagem mais orientada a objetos, que recomendo a todos.

O novo design do aplicativo envolveu praticamente duas classes principais, uma que representa as noticias chamada Noticia e outra que faz a persistência do objeto Noticia no banco de dados Access chamada NoticiaDAO (DAO = Data Access Object).

Uma rápida engenharia reversao do código no Visio me retornou esse modelo das duas classes:

Com essa abordagem ficou tudo muito fácil. Quando quero listar as noticias, simplesmente instancio um objeto DAO e executo o método ListarNoticias, que me retorna um ArrayList (parecido com o TObjectList do Delphi) com objetos Noticia. Quando uma noticia é alterada ou incluída, executo o método SalvarNoticia do DAO e a noticia é salva no banco. O mesmo para exclusão.

Ou seja, toda a lógica e componentes de acesso ao banco de dados ficam internos a classe DAO, e não espalhados pelo aplicativo. Isso facilita a manutenção de forma absurda. Imagine que amanhã quero utilizar Firebird ao invés de Access. Onde preciso mexer? Somente na classe DAO. Ou então quero salvar em XML e não usar mais banco de dados. Onde preciso mexer? Somente na classe DAO. Notou a facilidade? Se eu tivesse usado a primeira abordagem, teria que alterar TODAS as páginas para modificar o meio de persistência.

E em .NET essa abordagem é ainda mais fácil de ser utilizada pois o DataGrid por exemplo, aceita um ArrayList como DataSource e simplesmente lista todos seus objetos na grid, sem nenhuma codificação adicional! É fantástico. O bom é que isso vale para Delphi .NET também!

Claro, esse é um exemplo extremamente simplista, mas não deixa de mostrar como você pode facilitar sua vida e produzir software de melhor qualidade utilizando objetos de negócio.