Faca de dois gumes

Com a chegada do Entity Framework e do LinqToSql chegam com eles algumas dúvidas arquiteturais interessantes. A que tenho mais discutido é a seguinte: como faço para enviar num WebService meus objetos de negócio?

Primeiro, a boa notícia: tanto o LinqToSQL quanto o Entity Framework oferecem facilidades de serialização. O link https://msdn.microsoft.com/en-us/library/bb546184.aspx  mostra como isto funciona no LinqToSQL. O link https://msdn.microsoft.com/en-us/library/bb896304.aspx fala da serialização no Entity Framework. Isto torna simples disponibilizar objetos através de serviços WCF. Bom, não é?

Você deve estar esperando uma má notícia, certo? Bem, não tenho uma, mas sim um conselho: minha vivência diz que contratos de dados para serviços têm função e tempo de manutenção diferente dos dados de um banco de dados. Amarrar o esquema do banco com esquema de contratos de serviços é uma faca de dois gumes: por um lado, é simples; por outro, pode levar a um excesso de manutenção, uma vez que seus objetos estarão sujeitos a duas fontes de mudanças - contratos de serviço e modelo lógico/físico.

Esta dor pode ser amenizada com o uso do Entity Framework, já que ele possui uma camada de mapeamento entre conceitual e físico, e o nível conceitual costuma estar perto do que queremos passar em contratos de serviço.

Para projetos maiores, tendo a preferir definir duas classes de objetos – classes que definem os contratos e classes para mapear as entidades de negócio. O esforço pode parecer duplicado, mas, se eu estiver certo, poderá ter menor custo de manutenção, e manutenção costuma custar cerca de 70% do custo de um software.

E você o que acha?

Comments

• Anonymous
  August 20, 2008
  Otávio, Acho que além do custo de manutenção, o anseio em ser "early adopter" tem feito o pessoal usar indiscriminadamente mapeamento de objetos relacionais e serialização. Acredito que o ORM não deve ser utilizado em processos que tenham como escopo performance. Estes processos devem estar o mais próximo possível do repositório de dados e não se valer de uma camada a mais. Parece que nos esquecemos que quanto mais passos são necessários para chegar ao nosso objetivo, maior será a latência e o risco de uma das centenas das nossas camadas e fronteiras apresentarem algum defeito. Já me deparei com alguns problemas de desempenho (em produção) porque o desenvolvedor estava usando o LINQ TO SQL num cenário que só era necessário um DataReader. Imagine se ele ainda serializa-se este objeto para outra camada de serviço? Acho que toda a tecnologia vem para ajudar, mas devemos utilizá-la ao nosso favor, não acha? []s Alexandre.

• Anonymous
  August 20, 2008
  Alexandre, Confesso que sou pelo mínimo esforço de engenharia de acordo com o contexto. Me explico: se um ORM satisfaz boa parte dos casos, pecando por desempenho em pequenas situações, eu o utilizo. Invisto em maior engenharia e tempo apenas para a exceção. Meu blog http://blogs.msdn.com/otavio/archive/2008/07/20/desempenho-com-economia.aspx conta uma história relacionada a este tema. Abraço, Otavio

• Anonymous
  August 20, 2008
  Concordo com você, tudo depende do contexto, e PoC sempre ajuda. Acho uma boa prática não estabelecer um único padrão de acesso a dados numa aplicação que necessite de desempenho. Para tarefas que não existe o requisito, podemos nos valer de mapeamentos, contratos, serialização e serviços. Acredito que o que custa muito mais caro do que projetar para desempenho é identificar a ausência desde desempenho na produção num processo crítico depois que foi implantado e verificar que isto era um pré-requisito. Mapear estes pontos do projeto antes da codificação é o momento ideal para escolher quais tecnologias serão utilizadas e em que ponto.   Você escreveu um excelente artigo sobre esse assunto: http://blogs.msdn.com/otavio/archive/2008/03/22/t-sql-dal-ou-orm.aspx []s