Oi,Participando de uma reuniao aonde precisava apresentar conceitos tecnicos sobre o Dynamics CRM fui questionado a cerca do seguinte tema:"Como posso ter certeza de que o codigo que o progamador esta produzindo nao esta amarrado a uma versao especifica 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 voce utilizou para ler a frase acima, pode acreditar. Isto porque o cliente esta decido a trocar uma ferramenta que ja esta em producao por mais de 10 anos em sua operacao de call center.Esta decisao foi tomada, pois na nova versao do produto ele tera que praticamente reescrever toda suas regras de negocios, ja que toda a customizacao esta literalmente engessada na versao atual do produto.Minha resposta foi bem simples e objetiva:"So precisamos evitar o conceito OEF (Orientacao a Entidade e Formulario)". Explico:Tenho percebido ao longo do tempo que o Modelo Anemico 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 solucao de Call Center."Uma aplicacao totalmente engessada a versao corrente."Abaixo um exemplo de codigo OEF: (Algumas instrucoes 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 nao possuem comportamento, caracterizando-se assim como classes anemicas. Isto e ate compreensivel, pois o MS CRM e um produto que pode atender a diversos segmentos e ter que respeitar regras dos mais diferentes tipos, como instituicoes financeiras, construtoras e empresas de cosmeticos.Contudo construir um codigo anemico pode e deve ser evitado.Uma maneira e utilizando conceitos como desacoplamento, abstracao e, lembrar um pouco de como era trabalhar com o ADO.Net.Neste momento voce 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 voce programar com o Sdk do Dynamics CRM sua biblioteca de acesso a dados estava basicamente baseada no ADO.Net. Agora esta mesma biblioteca esta baseada em entidades geradas pelo CrmService.Vejamos um exemplo pratico: (Algumas instrucoes 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 Codigo acima e muito familiar, estou certo?Agora vejamos o codigo abaixo, utilizando o Sdk do Dynamics CRM: (Algumas instrucoes 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 sao 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 metodos caracteriza-se por um objeto de dominio, utilizando inclusive o Ubiquitous Language no nossos codigo fonte, atraves do termo Cliente ao inves de account, como