Este é um post disponível para assinantes MVPDesign 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.
[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;
09
10 Lista.Add(Tarefa);
11
12 MostrarTarefas();
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
2 COMENTÁRIOS
return
(IEnumerable<T>)_conexao.QueryByExample(exemplo);

0
0
