Eu sempre falo que não é a melhor situação do mundo trabalhar com EF em contextos de aplicações distribuidas, ou mesmo em uma onde você não guarde o contexto do EF por muito tempo, como no caso de uma aplicação web onde você guardou uma entidade do EF na sessão, mas não o contexto.

<parêntesis>
Aliás, isso é boa prática: nunca mantenha o contexto na memória muito tempo. As entidades ficam desatualizadas, e o EF faz cache, o que ocupa espaço e mata sua escalabilidade.
</parêntesis>

O Danny Simmons, do time de ADO.Net e que trabalha no EF, é sempre um cara transparente e legal de ler. E agora ele vem deixar claro que não é mesmo muito fácil usar EF nesses contextos de aplicação distribuida. Vale a pena dar uma olhada na solução que ele propõe para o problema.

Mas ele ressalva algo que eu já disse várias vezes: se sua entidade tem relacionamentos, esquece, vai dar problema. Melhor ir no banco, buscar a entidade, atualizá-la, e submeter o update. Não espere ser capaz de recriar a entidade do zero e submeter o update para uma entidade com relacionamentos. Isso vai ser resolvido na versão 2.0 do EF, que vai sair junto com o .Net 4.0, e que eu estou muito ansioso para ver. Nesses cenários ainda é melhor usar NHibernate (pelo menos até a próxima versão do EF, quando vou reavaliar isso).

Veja o blog post dele aqui.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.