Uma das maiores queixas sobre o ADO.NET Framework Entity e o LINQ to SQL, foi de que ele não suporta o monitoramento de mudanças. Você pode mudar os objetos e salvá-los de volta ao banco de dados, mas só se você estiver conectado a um objeto de contexto. Uma vez que o objeto de contexto sai do escopo, que como uma conexão de banco de dados deveria ser muito rápida, os objetos de dados essencialmente tornam-se apenas de leitura. Simplesmente não há uma boa forma de reanexá-los a um novo contexto para reescrever suas alterações.
A recusa da Microsoft em resolver isso é decididamente intrigante. Em vez de adicionar monitoramento de mudanças dentro do objeto de dados, como a maioria das bibliotecas ORM fazem, eles estão no focando mais em POCO ou "Plain Old C# Objects".
No blog de Entity Framework Design, três desenvolvedores da Microsoft passam por alguns dos métodos populares de acesso à banco de dados. Em primeiro lugar está o ADO.NET DataSet, que é inteiramente capaz de reescrever o conjunto de alterações para o banco de dados. Eles listam quatro "problemas" com o ADO.NET DataSet, dos quais nenhum faz muito sentido. Todos eles estão focados no envio dos conjuntos de mudanças através de limites não confiáveis, o que também não faz muito sentido. O acesso ao banco de dados e bibliotecas ORM foram criados para esterilizar os dados que devem ser controlados pela própria aplicação.
Em seguida estão todos os DTOs ou Data Transfer Objects. Este é apenas uma outra forma de dizer, "Nós enfiamos todos os dados em alguns objetos, agora você se vira com eles." Isto não é realmente relevante no centro da discussão mas mostra o que eles estão pensando sobre isso.
Este tópico é seguido por uma breve menção de REST. Agora vemos que a equipe do Entity Framework tem uma visão completamente perdida do que eles estão supostamente construindo. Sobre "as metas" eles dizem:
Com as melhorias deN-camadas para o Entity Framework, nós queremos tratar alguns dos mesmos problemas de espaço como DataSet, mas queremos evitar os principais problemas com ele.
Ideologicamente, nós gostaríamos de fornecer blocos de construção que sejam interessantes para desenvolvedores construirem soluções sobre uma variedade de arquitetura. Por exemplo, gostaríamos de fornecer controle suficiente de proponentes de DTO, mas ao mesmo tempo reduzir o nível de sofrimento daqueles que tentaram enfrentar experiências de cenários mais simples hoje em dia.
Agora o problema é mostrado claramente; O Entity Framework não quer ser apenas mais um ORM, quer seja tudo para todos. Como temos observado de tempo em tempo, esta abordagem geralmente não faz ninguém feliz. Considere desta declaração da equipe:
Além desses dois, há algumas representação genéricas interessantes para mudanças em um grafo, mas em geral, todos eles sofrem das mesmas desvantagens: determinando uma solução para eles não dá aos usuários um nível de controle que os cenários mais complicados e padrões mais sofisticados requerem.
Esse é seguido com,
Entity Framework não irá definir sua própria representação única para o conjunto de mudanças representadas em um aplicativo de N-camadas. Ao invés disso, vai disponibilizar blocos básicos para a construção de APIs que vão facilitar o uso de um amplo conjunto de representações.
Já que eles não podem oferecer uma solução 100% para o problemade manipular os conjuntos de mudanças, , eles não vão dar nada aos desenvolvedores. Os desenvolvedores têm que construir seu próprio ORM em cima do Entity Framework se eles realmente querem manipular dados fora do contexto.
O resto do artigo é de um exemplo contrário de como realizar até mesmo simples mudanças de monitoramento usando sua nova API. Isso envolve a criar uma interface como IEntityWithChanges, mapeá-la usando um método escrito à mão como GetEntityState e usando ambos em um método que recebe um objeto de contexto, nome do estado de entidade , grafo da entidade e um mapa do estado da entidade. Lembre-se isto é apenas para salvar as alterações, você ainda tem que de alguma forma rastrear asmudanças.
Ayende Rahien explica como deve ser feito:
Aqui está como você faz usando o NHibernate:
session.Merge( entityFromPresentationLayer );
O LLBLGen do Frans suporta uma característica muito semelhante. Em outras palavras, é problema do framework de acesso a dados fazer isso, não é problema dos desenvolvedores fazer tal coisa.
Falando doFrans Bouma, aqui está o resumo da situação,
E como todos esses desenvolvedores que usam Datasets agora serão convencidos que o ER é o caminho certo a seguir? Quando o DataSet resolveu este problema desde... bem, do principio? Sem mencionar o monte de frameworks O/R competidores por aí? O problema de tudo isto, eu acho, é o erro de projetar o framework a partir da perspectiva do desenvolvedor de framework: quando você escreve um framework existem dois tipos de 'correto': o do ponto de vista dos desenvolvedores de framework e o do ponto de vista dos usuários do framework. O erro principal está em assumir que estes dois tipos 'correto' são os mesmos, ou pior: supor que o conceito do desenvolvedor de framework do que é 'correto' é na verdade o que o usuário de framework quer.