Estava lendo um post do “TheServerSide .NET” sobre uma discussão referente à regras de negócio em entidades ORM.

A Questão levantada era aonde seria o melhor lugar para codificar as regras de negócio (incluem-se nela as regras de controle de registro duplicado “se for o caso”, validação de campos “tais como campos nulos, datas, etc”, entre outros) e como elas iriam de fato funcionar.

A dispeito de tudo o que se possa dizer, ainda sou de opnião que os objetos devem ser responsáveis pela própria validação e pela validação de seus filhos diretos.

Vamos explicar melhor.

Pensemos em um modelo (Cliente, Pedido, Produto e Estoque).

As regras de negócio do Cliente devem estar na própria classe de Cliente (quando muito em uma classe “Helper” separada), bem como as regras das classes de Pedido, Produto e Estoque devem estar em suas respectivas classes.

Mas porque eu penso assim?

Vamos analisar os seguintes pontos:
- Produtividade: As validações estando na própria classe (ou em um Helper de Validação da Classe) tornam a codificação menos complicada, com menos código e portanto mais produtiva.
- Manutenção: A equipe saberá aonde encontrar as regras de validação e não precisará procurar em todos os projetos da solução.

Ainda vamos analisar o item mais importante da lista, a SIMPLICIDADE.
Sim, isso mesmo.
As validações devem ser simples.
Imagine o caso: O “Cliente” possui um campo “Razão Social” que não pode ser nulo. Então, a forma mais simples de validar seria todas as vezes que a propriedade do campo “Razão Social” fosse alterada.

De fato que, uma entidade (interprete como “objeto” se assim desejar) ORM deve sempre consultar as validações antes de prosseguir com a persistencia dos dados no banco de dados certo?

Então, se verificarmos a propriedade no momento em que ela é alterada podemos controlar uma flag (esse seria o modelo mais simples) que indicaria se a classe está apta a ser salva ou não.

Da mesma forma os filhos (o que nós chamamos de “link”) funcionariam.

Entenderam?

Posts Relacionados:

1. Faça seu Gerador de Código com o T4 do Visual Studio – Use com Parcimônia