O DataAnnotations foi introduzido inicialmente na plataforma .NET para atender as necessidades de validação em aplicações Web, feitas com ASP.NET MVC e Silverlight. Esse artigo é sobre como aproveitar os recursos do DataAnnotations também em aplicações WPF, implementado o padrão Notifications.
Para que serve
Os recursos de DataAnnotations tem o principal objetivo de oferecer validação de dados em aplicações Web. Com ele é possível determinar regras de validação junto ao modelo de entidades do projeto. Além de atender bem essa necessidade em aplicações Web, o DataAnnotations também pode ser aproveitado em aplicações Clientes, como Windows Forms e WPF.
Em que situação o tema é útil
Criar mecanismos de validação de dados é sempre uma tarefa árdua, principalmente se é necessário prezar por boas práticas e padrões da orientação a objetos. O DataAnnotations pode ser facilmente implementado com a utilização do Notification Pattern, um famoso Design Pattern voltado para a modelagem de mecanismos de validação.
Resumo do DevMan
Validação de Dados é um assunto muito crítico no processo de desenvolvimento de aplicações. Existem dezenas de opções e formas de se validar uma informação que é fornecida pelo usuário. A validação pode ocorrer na própria camada de apresentação, impedindo que o dado incorreto chegue às camadas mais internas do aplicativo. A validação ainda pode ocorrer numa camada responsável pelas regras de negócio, ou ainda no próprio banco de dados. Esse artigo fala sobre como usar o DataAnnotations para padronizar o mecanismo de validação de uma aplicação WPF, e ao menos tentar isolar todas, ou a maioria, das regras de validação, junto com o modelo do projeto.
Modelar é preciso, validar não é preciso. Assim como a frase de Fernando Pessoa (Navegar é preciso, viver não é preciso), essa é uma afirmação bastante ambígua. É claro que ao interpretar a palavra “preciso” como necessário, as práticas de Modelagem e Validação são ambas, extremamente necessárias na arte de se desenvolver software.
Mas, ao considerar que a frase fala de precisão técnica, e não de necessidade, sabemos que a Modelagem do Software é uma prática muito mais precisa do que a validação de dados.
Validar é necessário, mas não é uma prática muito precisa hoje em dia. Hoje é natural encontrar regras de validação espalhadas em várias partes de um projeto, mesmo que esse projeto tenha sido arquitetado com as melhores práticas de desenvolvimento do mercado.
É muito comum encontrar regras na camada de Domínio, junto com Entidades e regras de negócio. É comum também encontrar regras de validação no próprio banco de dados, com a utilização de mecanismos do próprio sistema de gerenciamento do Database. E é ainda mais comum encontrar validação na camada de apresentação da aplicação, com a utilização de controles que realizam a validação do dado logo no input do usuário.
Mas qual é a melhor forma de se validar os dados que são fornecidos pelo usuário em uma aplicação? Existe uma regra bem definida? Há técnicas e modelos que ditam onde é correto criar os mecanismos de validação? A resposta para essas questões por muito tempo foi negativa, ou pior, por muito tempo não se deu a devida importância para essas questões.
Esse artigo abordará exatamente esse caso, mostrando que existem boas práticas para validação sim, e mais do que isso, existem ferramentas para modelar regras de validação de uma forma eficaz e compatível com os melhores princípios e práticas do desenvolvimento de aplicações com a orientação a objetos.
Notification Pattern
O Notification Pattern, ou padrão de notificação, é um padrão de projeto que determina como modelar um mecanismo de notificação, compatível com a camada de Domínio de um projeto. Na seção de Links desse artigo estão listadas duas ótimas referências sobre Notification Pattern. A primeira é a definição do Martin Fowler sobre o padrão de Notificação. Martin Fowler que é uma sumidade quando o assunto é Design Patterns. O segundo link é de um artigo sobre esse mesmo tema, escrito por Jeremy D. Miller.
Segundo Fowler, um objeto Notification é qualquer objeto que coleta informações sobre erros ou qualquer outra informação relevante na camada de domínio, e comunica essas informações para a camada de apresentação. Por esse motivo o padrão de notificação cabe muito bem em um mecanismo de validação, para uma aplicação modelada através dos conceitos do DDD (Domain Driven Design).
DDD é uma dessas siglas que aparecem na área de tecnologia e que muita gente fica sem saber exatamente o que é. DDD é Domain-Driven Design, um termo que se tornou muito famoso depois da publicação do livro Domain-Driven Design: Tackling Complexity in the Heart of Software, de autoria de Eric Evans e publicado pela editora Addison-Wesley. Esse livro é leitura obrigatória para todo desenvolvedor que deseja desenvolver aplicações verdadeiramente orientadas a objeto.
Domain-Driven Design, como o próprio nome diz é uma forma de se construir software orientando toda a atenção para o Domínio da aplicação. O domínio da aplicação é o contexto em que o software irá trabalhar. Se você vai fazer um software para controle de uma farmácia, todos os processos que envolvem o funcionamento da farmácia fazem parte do domínio.
O domínio da aplicação deve ser expresso e modelado através de uma linguagem ubíqua (Ubiquitous Language), onde os termos usados têm de ser comuns e conhecidos por todos envolvidos, principalmente aqueles que mais entendem do domínio, os Domains Experts.
Um dos pontos fundamentais do DDD está na modelagem do domínio. E quando se pretende aplicar DDD, é na modelagem do domínio que se encontra as mudanças mais concretas.
Se antes (sem o DDD) começavam-se as aplicações modelando um banco de dados, com o DDD é preciso primeiro modelar um domínio. Um domínio é muito mais do que uma simples estrutura de dados, nele devem estar todas as regras de negócio que determinam o comportamento que a aplicação deverá ter.
Sendo assim, a modelagem de um domínio é muito mais complexa, e impossível de se fazer simplesmente através de um banco de dados. Para modelar um domínio são necessários recursos da Orientação a Objetos, e por isso, para adotar o DDD é necessário utilizar linguagens orientadas a objetos.
Enquanto na modelagem de um banco de dados são estruturadas Tabelas e Relacionamentos, no DDD um modelo é composto de: Entidades, Objetos de Valor, Associações, Agregações, Factories, Serviços e Repositórios (entre outros tipos de objetos).
Na forma mais simples possível, um objeto de Notificação é uma mensagem na forma de string. Um objeto de notificação um pouco mais elaborado irá carregar informações mais precisas sobre essa mensagem, mas continua sendo uma string. A Listagem 1 mostra um exemplo claro do que é um objeto de notificação.
Listagem 1. Classe abstrata Notification
...
