Design Patterns na prática – Artigo .net Magazine 79 - Parte 4

Este artigo ensina como aplicar o padrão Repository para persistência de dados. Aborda conceitos de encapsulamento e polimorfismo, além de mostrar a implementação dos padrões Command e Singleton.

.net Magazine 79

[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]

> Clique aqui para ler todos os artigos da .net Magazine 79

Design Patterns na prática – Parte 4

Command, Singleton e Repository

Do que trata o artigo

Este artigo ensina como aplicar o padrão Repository para persistência de dados. Aborda conceitos de encapsulamento e polimorfismo, além de mostrar a implementação dos padrões Command e Singleton.

Para que serve

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.

Em que situação o tema é útil

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.

Resumo do DevMan

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.

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.

· Listagem 1. Código para criar e adicionar uma nova tarefa

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;

10 Lista.Add(Tarefa);

12 MostrarTarefas();

ATENÇÃO! A exibição deste artigo foi interrompida.

Este é um post disponível para assinantes MVP

Este post também está disponível para assinantes da .net Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!

2 COMENTÁRIOS

[Fechar]

Este post é fechado - você precisa ter acesso ao post para incluir um comentário.

Rogerio Calixto

Muito legal o artigo...

Uso o VS2008 e estou fazendo os estudos do material. Porém me deparei com o seguinte problema:

No arquivo RepositorioDB4o.cs, na impelementação do método GetPorExemplo da classe RepositorioDb4o<T> tem a linha de comando:

return _conexao.QueryByExample(exemplo).Cast<T>();

Porém quando dou um Build dá a mensagem: "Db4objects.Db4o.IOobjectSet does not contain a definition for 'Cast' accepting a first argument of RepositorioDB4o"

Imaginei que este seria um recurso implementado apenas para o VS2010 e alterei a linha para:

return (IEnumerable<T>)_conexao.QueryByExample(exemplo);

Aí consigo compilar, mas ao executar e chegar nessa linha de código gera a exceção :

InvalidCastException

Não é possível converter um objeto do tipo 'Db4objects.Db4o.Internal.Query.ObjectSetFacade' no tipo 'System.Collections.Generic.IEnumerable`1[TesteDaFabrica.PessoaTeste]'

Como posso resolver este problema sendo que uso o VS2008 ?

em 1/12/2010 15:56 - Responder