Quebrando o paradigma OEF

Oi,

Participando de uma reunião aonde precisava apresentar conceitos técnicos sobre o Dynamics CRM fui questionado a cerca do seguinte tema:

"Como posso ter certeza de que o código que o progamador está produzindo não está amarrado a uma versão específica do produto? Como vou conseguir me beneficiar de todas as novas features da nova plataforma do Dynamics CRM 5.0 e todas as outras que vierem pela frente?"

A pergunta acima teve um tom muito mais preocupante do que o que você utilizou para ler a frase acima, pode acreditar. Isto porque o cliente está decido a trocar uma ferramenta que já está em produção por mais de 10 anos em sua operação de call center.

Esta decisão foi tomada, pois na nova versão do produto ele terá que praticamente reescrever toda suas regras de negócios, já que toda a customização está literalmente engessada na versão atual do produto.

Minha resposta foi bem simples e objetiva:

"Só precisamos evitar o conceito OEF (Orientação a Entidade e Formulário)". Explico:

Tenho percebido ao longo do tempo que o Modelo Anêmico gerado pelo Dynamics CRM conduz os desenvolvedores por um caminho que muitas vezes pode ir de encontro ao problema que levou o cliente a decidir trocar sua solução de Call Center.

"Uma aplicação totalmente engessada a versão corrente."

Abaixo um exemplo de código OEF: (Algumas instruções foram ocultadas para um melhor entendimento).

public Guid Salvar(account cliente) {

var servico = new CrmService();

return servico.Create(cliente);

}

Se avaliarmos o exemplo acima e o modelo gerado pelo CrmService vamos perceber que as classes/entidades não possuem comportamento, caracterizando-se assim como classes anemicas. Isto é até compreensível, pois o MS CRM é um produto que pode atender a diversos segmentos e ter que respeitar regras dos mais diferentes tipos, como instituições financeiras, construtoras e empresas de cosméticos.

Contudo construir um código anêmico pode e deve ser evitado.

Uma maneira é utilizando conceitos como desacoplamento, abstração e, lembrar um pouco de como era trabalhar com o ADO.Net.

Neste momento você pode estar se perguntando: O que as classes geradas pelo CrmService tem em comum com as classes do ADO.Net?

Resposta muito simples: T.U.D.O!!!

Antes de você programar com o Sdk do Dynamics CRM sua biblioteca de acesso a dados estava basicamente baseada no ADO.Net. Agora esta mesma biblioteca está baseada em entidades geradas pelo CrmService.

Vejamos um exemplo prático: (Algumas instruções foram acultadas para um melhor entendimento)

public int Salvar(Cliente cliente) {

var parametro = new SqlParameter("@nome", cliente.Nome);

var comando = new SqlCommand("Insert Into Cliente(nome) Values(@nome)", "SqlConnection");

comando.Parameters.Add(parametro);

return comando.ExecuteNonQuery();

}

O Código acima é muito familiar, estou certo?

Agora vejamos o código abaixo, utilizando o Sdk do Dynamics CRM: (Algumas instruções foram ocultadas para um melhor entendimento)

public Guid Salvar(Cliente cliente) {

var parametro = new account();

parametro.name = cliente.Nome;

var servico = new CrmService();

return servico.Create(account)

}

Se analizarmos bem friamente os dois exemplos acima veremos que são muito parecidos no conceito, pois ambos encapusulam dos consumidores os objetos utilizados para manipular dados em alguma fonte de dados, seja ela um banco de dados ou um web service.

Ainda nos exemplos acima podemos notar que a assinatura dos métodos caracteriza-se por um objeto de domínio, utilizando inclusive o Ubiquitous Language no nossos código fonte, através do termo Cliente ao invés de account, como sugerido pelo Dynamics CRM.

A utilização de um modelo Orientado a Objetos é complexa e por isto é necessário ter cuidado quando se deseja adotar tal técnica. No entanto está mais do que comprovado de que é uma técnica que, quando bem aplicada, traz resultados significativos em termos de manutentabilidade e evolução do aplicativo. Sendo assim vale a pena um estudo de caso.

Para concluir gostaria de enfatizar que a utilização dos conceitos OEF não é uma evolução em sua carreira, ao contrário, vejo isto como algo que pode levá-lo ao comodismo e a prática de uma programação monopolista, engessada e amadora. Por isto reveja seus conceitos, entenda os principios da Orientação a Objetos e como aplicá-la ao mundo Dynamics, pois ao contrário do que pode parecer é uma prática totalmente viável, elegante e produtiva.


[]'s

Ricardo Simões