Entity Framework 4 / POCO - Por onde começar? [fechadas]


183

Venho programando há algum tempo e já usei LINQ-To-SQL e LINQ-To-Entities antes (embora, ao usar entidades, ele tenha um relacionamento Entidade / Tabela 1-1 - ou seja, não seja muito diferente do L2SQL)

Eu tenho lido muito sobre Inversão de Controle, Unidade de Trabalho, POCO e padrões de repositório e gostaria de usar essa metodologia em meus novos aplicativos.

Onde estou lutando é encontrar um guia claro e conciso para iniciantes do EF4, que não pressupõe o conhecimento do EF1.

As perguntas específicas que preciso responder são:

Código primeiro / modelo primeiro? Prós / contras em relação ao EF4 (ou seja, o que acontece se eu codificar primeiro, alterar o código posteriormente e precisar regenerar meu modelo de banco de dados - Os dados são preservados, transformados ou descartados?)

Supondo que eu vou primeiro o código (eu gostaria de ver como o EF4 converte isso em um esquema de banco de dados) como eu realmente começo? Muitas vezes, vi artigos com diagramas de entidades dizendo "Então este é o meu modelo de entidade, agora vou ..." - Infelizmente, não sei se eles criaram o modelo no designer, mas o salvaram em gerar código e interromper qualquer nova geração de código automático - ou - Eles codificaram (POCO)? classes e de alguma forma as importou para a visualização deisgner?

Suponho que o que realmente preciso é entender de onde vem a "mágica" e como adicioná-la eu mesmo, se não estiver apenas gerando um modelo EF diretamente de um banco de dados.

Estou ciente de que a pergunta é um pouco vaga, mas não sei o que não sei - portanto, qualquer entrada / correção / esclarecimento é apreciada.

Escusado será dizer que não espero que ninguém se sente aqui e me ensine EF - eu gostaria de alguns bons tutoriais / fóruns / blogs / etc. para iniciantes completos da entidade


3
tenha muito cuidado com a vida útil de suas conexões: bit.ly/fi83NV É algo que você realmente deve estar ciente ao abstrair contextos em repositórios. Pode parecer estar funcionando, mas, na verdade, lentamente, registrando mais e mais conexões abertas
BritishDeveloper

@ BRitishDeveloper - Muito bom conselho. Isso realmente nos chamou a atenção, mas da maneira oposta - estávamos usando um contêiner de IoC para recuperar repositórios e tivemos um problema em que o contexto atribuído ao repositório fechava a conexão após um período de tempo, mas não era sinalizado como descartado / semelhante. Eventualmente, estendemos o contexto com um IsDisposed () que foi verificado com o estado de descarte usual e o estado da conexão, permitindo construir outro, se necessário.
Básico

Outra dica útil é que, ao obter um novo contexto, os objetos associados ao contexto antigo não terão o rastreamento de alterações apropriado e causarão problemas de incompatibilidade de contexto. Portanto, se você tiver um aplicativo de longa duração e alterar o contexto no meio execução, você precisa recuperar todas as suas entidades. Para torná-lo mais interessante, na verdade, tivemos que ter duas rodando lado a lado às vezes e acabamos escrevendo algum código para mapear entre as duas muito bem ... #
Basic

1
@Basiclife Eu encontrei o mesmo problema :) Estou pensando em escrever meus pensamentos sobre a atualização de entidades desanexadas há um tempo e você acabou de me encorajar a fazer exatamente isso: britishdeveloper.co.uk/2011/03/…
BritishDeveloper 18/03/11

Respostas:


56

Esses artigos podem ser interessantes ... a série realmente aproveita as vantagens e desvantagens de uma abordagem POCO.

http://blogs.msdn.com/b/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx

http://blogs.msdn.com/b/adonet/archive/2009/05/28/poco-in-the-entity-framework-part-2-complex-types-deferredloading-and-explicit-loading. aspx

http://blogs.msdn.com/b/adonet/archive/2009/06/10/poco-in-the-entity-framework-part-3-change-tracking-with-poco.aspx

Nesses artigos, o autor menciona artigos futuros que descrevem as melhores práticas na implementação de padrões de Repositório e Unidade de Trabalho, mas não consigo encontrá-los. Estes artigos são bem escritos e eu gostaria de ler mais deste autor.


2
Como alguém que já se sente confortável com o Entity Framework usando o designer, essa foi uma excelente introdução ao POCO.
Nathanchere 28/09/10

1
Se você está procurando o acompanhamento da Unidade de Trabalho, ele está localizado em blogs.msdn.com/b/adonet/archive/2009/06/16/…
Mike


7

Eu recomendo que você tire meia hora ou mais e gere um modelo EF1.0 estável no seu VS atual. Isso ajudará você a entender as metáforas e os conceitos do EF 4.0. Basta criar um simples cliente, produtos e pedidos db ... Eu recomendo fazer o seu próprio e não usar Northwind.


4

Essa é uma ótima pergunta, mas difícil de manter atualizada, pois o Entity Framework continua amadurecendo. Provavelmente, o melhor lugar para começar que se manterá atualizado no futuro é a página EF da Microsoft .

Alguns outros links que achei úteis no Google (focado no Code First):


3

Você pode pegar o livro de Lerman ou algo mais simples como "Mapeamento relacional de objetos Pro linq". Todos os conceitos ainda são os mesmos do POCO, exceto que agora você deve desativar a geração de código e mapear diretamente para o seu modelo no edmx csdl (ou criar seu próprio gerador POCO). Todos os princípios de mapeamento também são os mesmos. De qualquer forma, em tempo de execução, você está trabalhando com proxy que é derivado do seu objeto POCO, portanto, você deve se preocupar com o suporte a interceptação (virtualização de suas propriedades POCO).



2

Aqui está uma explicação passo a passo sobre o modelo POCO para o Entity Framework que parecia muito bom. Você também pode conferir o blog da equipe do ADO.NET . Se você deseja começar do início (EF v1.0) como base para o seu conhecimento sobre EF, achei o livro Programming Entity Framework de Julia Lerman muito completo.


Obrigado - eu não tinha visto o livro, mas li os dois links fornecidos. A explicação passo a passo sobre o modelo é útil para explicar como funcionalidades adicionais podem ser adicionadas aos objetos POCO depois de definidos (por exemplo, carregamento lento), mas (e posso estar perdendo algo óbvio aqui), na verdade, não explica como começar (ou seja, simplesmente criar uma classe conforme especificado não a torna uma entidade nem a associa a um modelo) Eu tive uma experiência semelhante com o blog. Vou considerar a possibilidade de adquirir o livro - parece promissor - obrigado.
Básico

2
Em relação ao livro de Julia Lerman, vale a pena mencionar que ela está trabalhando em uma segunda edição da EF4: learnentityframework.com/LearnEntityFramework/book/… . Lembro que li em algum lugar que a data de publicação planejada é em maio deste ano, mas não consigo mais encontrar a fonte. Também acabei de encontrar este site: nakedobjects.net/home/index2.shtml
Slauma

Slauma, o link que você forneceu parecia exatamente o que eu precisava - exceto que ele usa uma biblioteca de "Naked Obects" de terceiros que parece estar ofuscando a complexidade de alguma forma - Por um minuto, pensei que você tivesse decifrado
Basic


1

Julia Lerman tem uma boa série de vídeos introdutórios , com cerca de 10 minutos cada. Eles são introdutórios, mas existem muitas dicas práticas que tiram algumas barreiras de aprendizado em potencial. Eu gostei especialmente da demonstração dela de assistir o SQL real usando o SQL Server Profiler.


1

Se você for usar cenários desconectados, recomendo que você leia o livro de Julie Lerman: "Programming DbContext", em especial no Capítulo 4.

Encontrei muitos exemplos em blogs, etc., mas quase todos são sobre cenários conectados.

Eu também estou começando. e esse livro me ajudou muito. A propósito, eu comprei três livros para ela.



0

Uau, muitas respostas. Que tal um exemplo que contém uma versão aprimorada dos modelos T4 que geram repositórios POCO + interfaces +?

https://entityinterfacegenerator.codeplex.com


Interessante e útil para testar repositórios / contextos, mas por que você precisaria abstrair as próprias entidades? Por definição, eles não devem ter nenhum código funcional dentro deles.
Básico

Você está certo. Principalmente, as pessoas não precisam ter interfaces separadas. Mas ajuda pessoas que desejam resolver referências circulares e desejam compartilhar as interfaces, não as classes reais, com terceiros. Isso ajudará bastante se sua empresa precisar passar por uma auditoria com integração de terceiros, que não requer implementação detalhada no compartilhamento.
Believe2014
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.