Por que eu devo ler este artigo:Um programa orientado a objetos precisa converter as informações do banco de dados em objetos antes de manipulá-las. Aprendendo como fazer isto através de frameworks e padrões de projetos você está garantindo uma vantagem em relação à concorrência. Segundo o que este artigo propõe você terá um sistema muito fácil de manusear, capaz de atender as necessidades que o dia a dia impõe. As técnicas aqui apresentadas serão úteis, por exemplo, para mostrar como usar boas práticas em um exemplo real, além de fortalecer importantes regras da OO, como separação de responsabilidades e implementação correta de padrões de projeto.

Se você leu a terceira parte desta série, você aprendeu o quanto é importante criar classes que tenham apenas uma única responsabilidade. Também aprendeu a identificar as responsabilidades de uma classe e como fazer para separá-las. Agora está na hora de criar o banco de dados da aplicação. É claro que o resultado deve ser um código flexível o suficiente para que o SGBD possa ser alterado com pouco esforço.

Na última parte desta série o agendador sofreu grandes modificações. O comportamento do sistema continua o mesmo, pois nenhuma nova função foi adicionada. Porém internamente muita coisa mudou. Em outras palavras, o agendador continua fazendo a mesma coisa, mas de maneira diferente. O principal problema que foi corrigido na segunda versão (parte 3) era o acúmulo de responsabilidades sobre a classe do formulário, pois esta classe possuía todas as regras de negócios da aplicação. Após identificar este problema, o que fizemos, foi separar estas responsabilidades em mais classes e o design do sistema ficou como o apresentado na Figura 1.

Design atual do sistema
Figura 1. Design atual do sistema

Uma vez que a maioria dos problemas de engenharia foi corrigida, está na hora de implementar uma das funções mais importantes: salvar as informações no banco de dados. Até agora o aplicativo não persiste as informações, ao invés disto, cada tarefa é adicionada a uma variável do tipo List e é claro que quando o sistema é fechado esta lista é perdida. Agora que o sistema já está mais maduro é possível implementar a persistência dos objetos.

O objetivo da alteração

É preciso retirar da classe do formulário toda a responsabilidade referente ao ato de salvar informações. Como você pode ver na Listagem 1, o código para salvar uma tarefa é muito simples, basta adicionar a nova tarefa na variável utilizada como banco de dados temporário da aplicação – veja linha 10 da Listagem 1. Normalmente é necessário mais código para salvar um registro como, por exemplo, abrir uma conexão, criar a tabela caso não exista, verificar se já existe um registro com o mesmo nome e somente depois salvar a tarefa. O que atualmente no agendador é representado apenas por uma linha, na vida real seriam várias linhas de códigos. O objetivo é separar toda essa lógica em classes que sejam responsáveis exclusivamente por persistir os objetos.


01 private void SalvarTarefa_Click(object sender, EventArgs e)
02 {
03     var Tarefa = new Tarefa();
04     Tarefa.Comando = Comando.Text;
05     Tarefa.Nome = Nome.Text;
06     Tarefa.Parametros = Parametros.Text;
07     Tarefa.IniciarEm = IniciarEm.Text;
08     Tarefa.Comentario = Comentarios.Text;
09 
10     Lista.Add(Tarefa);            
11 
12     MostrarTarefas();
13 }
Listagem 1. Código para criar e adicionar uma nova tarefa

Quando dizemos persistir os objetos, nos referimos à ação de salvar as informações de todas as propriedades de um objeto no banco de dados e quando necessário for, buscar e colocar essas informações de volta em um objeto do mesmo tipo. Fazer isto de forma manual é possível, mas muito cansativo e o resultado não será bom, pois cada objeto possui diferentes propriedades. Por este motivo é óbvio que isso deve ser feito de modo automático.

Persistência de objetos

Salvar objetos que estão na memória para um meio físico pode ser trabalhoso, principalmente se optarmos por nós mesmos fazer essa tarefa. Existem frameworks que tiram esse trabalho de nossas costas, como o NHibernate e o Entity Framework. Contudo, estes são frameworks que fazem o chamado mapeamento objeto relacional, ou seja, transformam objetos em registros de um banco relacional, ou vice-versa. Mesmo sendo práticos, esses frameworks exigem que façamos esse mapeamento. Nosso projeto não exige um banco de dados relacional para armazenar os dados. Como faremos então?

Existe uma terceira opção. Os bancos de objetos. Estes são bancos de dados que salvam os objetos tal qual eles são no código fonte. Não há necessidade de se fazer mapeamento, agilizando assim o processo como um todo. No mercado temos algumas opções como o MongoDB, Caché, db4o e outros. Vamos optar pelo db4o, mas, sinta-se livre para experimentar outro banco.

Vamos organizar agora nosso modelo de classes, criando uma classe base, o que permitirá na sequência a criação de um repositório genérico.

Classe Bean

Esta classe será a base para as outras já existentes. Teremos nela apenas uma única propriedade, Id do tipo string. Essa propriedade servirá apenas como um identificador único para o objeto. No construtor da classe vamos instanciar um objeto Guid e passar seu valor para essa propriedade. Veja seu código na ...

Quer ler esse conteúdo completo? Tenha acesso completo