Este artigo foi traduzido por máquina.

Pontos de dados

Visualização da estrutura de entidades: o código em primeiro lugar, ObjectSet e DbContext

Julie Lerman

Enquanto o Entity Framework (FE) 4 ainda estava em beta, a equipe de desenvolvimento começou a trabalhar em outra maneira de usá-lo. Tivemos que o banco de dados - a primeira forma de criar um modelo (ao reverter a engenharia de um banco de dados em um modelo de dados de entidade) e o novo modelo de 4 EF - primeiro recurso (definir um modelo de dados de entidade, e crie o banco de dados a partir dela). Além disso, a equipe decidiu criar algo chamado “ código primeiro ”.

Com o código primeiro começar com o código — não o banco de dados e não ao modelo. Na verdade, com o código pela primeira vez há nenhum modelo visual e sem XML que descreve esse modelo. Basta criar as classes para o seu domínio de aplicativo e código pela primeira vez irá ativá-los participar do EF. Você pode usar um contexto, gravar e executar LINQ para consultas de entidades e aproveitar o controle de alterações EF. Mas não há necessidade de lidar com um modelo em um designer. Quando não estão criando aplicativos altamente arquitetados, você pode esquecer quase o EF até lá, é manipular todas as sua interação com o banco de dados e controle de alterações para você.

Ventiladores de desenvolvimento controlado por domínio (DDD) parecem adorar o código pela primeira vez. Na verdade, era um número de DDD gurus, que ajudou a equipe de EF entender pela primeira vez que o código pode fazer para programadores DDD. Confira a postagem de blog ’ Danny Simmons sobre a programação de dados Advisory Council para obter mais informações sobre esse ( blogs.msdn.com/b/dsimmons/archive/2008/06/03/dp-advisory-council.aspx ).

Mas o código não estava pronto para ser incluído no Microsoft .NET Framework 4 e do Visual Studio 2010 pela primeira vez. Na verdade, ele ainda está em evolução e a Microsoft está fornecendo aos desenvolvedores acesso aos bits de brincar com e fornecer feedback com o CTP de recurso do Entity Framework (CTP do Feature FE). A quarta iteração dessa visualização de tecnologia da comunidade (CTP4) foi lançada em meados de julho de 2010. As alterações feitas nessa iteração foram significativas.

Em adição a incluindo o assembly de código primeiro o CTP4, Microsoft tem trabalhado em algumas boas idéias novas para a próxima iteração do EF. Aqueles também estão incluídas no CTP4 para que as pessoas podem brincar com eles, mais uma vez, fazer comentários. Mais importante, o código primeiro tira proveito de alguns desses novos recursos.

Você pode encontrar um número de orientações detalhadas sobre este CTP nas mensagens no blogue pela equipe do EF (tinyurl.com/297xm3jde ), Scott Guthrie (tinyurl.com/29r3qkb ) e Scott Hanselman (tinyurl.com/253dl2g ).

Nesta coluna, quero que enfocam a alguns dos recursos específicos e melhorias no CTP4 que geraram uma quantidade incrível de agitação em torno do EF porque eles simplificam o desenvolvimento com o FE — e o .NET Framework em geral — portanto, consideravelmente.

Aprimoramentos para o núcleo da API

Um dos aprimoramentos digno de nota que o CTP4 adiciona ao runtime EF é uma versão simples das duas classes de força de trabalho, ObjectContext e ObjectSet. ObjectContext permite consultar, controle de alterações e salvar no banco de dados. ObjectSet encapsula os conjuntos de objetos semelhantes.

As novas classes, DbContext e DbSet, têm as mesmas funções essenciais, mas não expõem a todo o recurso conjunto de ObjectContext e ObjectSet. Não, todos os cenários de codificação exigem acesso a todos os recursos nas classes mais robustos. DbContext e DbSet não derivada de ObjectContext e ObjectSet mas DbContext fornece fácil acesso para a versão completa por meio de uma propriedade de: DbContext.ObjectContext.

Noções básicas do ObjectSet e o DbSet simplificado

Um ObjectSet é uma representação de tipo de coleção genérica de um conjunto de tipos de entidade. Por exemplo, você pode ter um ObjectSet <Customer>chamada Customers é uma propriedade de uma classe de contexto. LINQ to Entities consultas são escritas em relação a ObjectSets. Aqui está uma consulta em relação a ObjectSet Customers:

from customer in context.Customers 
where customer.LastName=="Lerman" 
select customer

ObjectSet tem um construtor interno e não tem um construtor sem parâmetros. A maneira de criar um ObjectSet é através do método ObjectContext.CreateObjectSet. Em uma classe de contexto típicos, a propriedade Customers seria definida como:

public ObjectSet< Customer> Customers {
  get { 
    return _ customers??
(_customers = 
      CreateObjectSet< Customer >(" Customers"));
  }
}

private ObjectSet< Customer > _ customers;

Agora você pode escrever consultas em relação a clientes e manipular o conjunto, adicionando, conectar e excluir objetos conforme necessário.

DbSet é muito mais simples de trabalhar com. DbSet não é publicamente construível (semelhante a ObjectSet), mas irá criar DbSets automaticamente e atribuí-los para todas as propriedades (com o públicos setters) declarar no seu DbContext derivado.

Os métodos de coleção ObjectSet são voltados para a terminologia EF — AddObject, anexar e DeleteObject:

context.Customers.AddObject(myCust)

DbSet usa simplesmente adicionar, anexar e remove, que é mais de acordo com os outros nomes de método de coleção, para que você não precisará perder tempo descobrir “ como dizer que em EF, ” da seguinte forma:

context.Customers.Add(MyCust)

O uso do método remover, em vez do DeleteObject mais claramente descreve também o que o método está fazendo. Remove um item de uma coleção. DeleteObject sugere que os dados serão excluídos do banco de dados, o que causou confusão para vários desenvolvedores.

De longe, o recurso favorito do DbSet é que ele permite trabalhar mais facilmente com tipos derivados. ObjectSet quebra tipos base e todos os tipos que herdam dele. Se você tiver uma entidade base, contato e uma entidade de cliente que deriva dela, toda vez que você deseja trabalhar com os clientes, você terá de iniciar com o ObjectSet de contatos. Por exemplo, para consultar os clientes, você escreve context.Contacts.OfType <Customer>. Isso não só é confuso, também, sem dúvida, não é facilmente identificável. DbSet lhe permite empacotar os tipos derivados, portanto, agora você pode criar uma propriedade Customers retorna DbSet <Customer>e permite a interação com isso diretamente, em vez de fazê-lo por meio do conjunto de contatos.

DbContext — um contexto simplificado

DbContext expõe os recursos mais usados do ObjectContext e fornece alguns outros adicionais que são realmente útil. Meus recursos favoritos dois até o momento de DbContext são a propriedade set genérica e o método OnModelCreating.

Todos esses ObjectSets eu ter mencionado até o momento são propriedades explícitas de uma instância de ObjectContext. Por exemplo, digamos que você tem um modelo chamado PatientHistory tem três entidades: Paciente, endereços e OfficeVisit. Você terá uma classe, PatientHistoryEntities, que herda de ObjectContext. Essa classe contém uma propriedade de pacientes que é um ObjectSet <Patient>Assim como uma propriedade de endereços e uma propriedade OfficeVisits. Se você quiser escrever código dinâmico usando os genéricos, você deve chamar context.CreateObjectSet <T>onde T é um dos tipos de entidade. Novamente, isso não é detectável.

DbContext tem um método mais simples, chamado de conjunto permite que você simplesmente chamar context.Set <T>, que retornará um DbSet <T>. Ele só pode parecer como 12 menos letras, mas a minha cabeça de codificação, usando a propriedade sentir direito, ao passo que chamar um método de fábrica não. Você também pode usar entidades derivadas com essa propriedade.

Outro membro DbContext é OnModelCreating, qual é útil em código pela primeira vez. Todas as configurações adicionais que você deseja aplicar ao seu modelo de domínio podem ser definidas em OnModelCreating antes do EF cria os metadados na memória com base nas classes de domínio. Esta é uma grande melhoria em relação às versões anteriores do código pela primeira vez. Você verá mais informações sobre esse assunto mais em.

Código primeiro obtém mais inteligente e mais fácil

Código primeiro foi exibido primeiro para desenvolvedores como parte do CTP1 de recurso EF em junho de 2009 com o nome “ código apenas. ” A premissa básica por trás dessa variação de usar o EF era que os desenvolvedores simplesmente querem definir suas classes de domínio e não se preocupe em um modelo físico. No entanto, o tempo de execução EF depende XML do modelo forçar consultas com base no modelo em consultas de banco de dados e os resultados da consulta do banco de dados de volta para objetos que são descritos pelo modelo. Sem esses metadados, o EF não pode fazer seu trabalho. Mas os metadados não precisam estar em um arquivo físico. O EF lê os arquivos XML, uma vez durante o processo do aplicativo cria objetos de metadados com rigidez de tipos com base em que XML e, em seguida, faz tudo de que a interação com o XML na memória.

Código cria objetos de metadados na memória muito. Mas, em vez de criá-la, lendo os arquivos XML, ele infere os metadados das classes de domínio (consulte do Figura 1). Ele usa a convenção para fazer isso e, em seguida, fornece um meio pelo qual você pode adicionar configurações adicionais para refinar ainda mais o modelo.

De código primeiro compila os metadados de modelo de dados de entidade em tempo de execução, a Figura 1

Pela primeira vez há outro trabalho importante de código usar os metadados para criar um esquema de banco de dados e até mesmo o próprio banco de dados. Código primeiro forneceu esses recursos desde a sua versão mais antiga do público.

Aqui está um exemplo de onde é necessário uma configuração para superar algumas suposições inválidas. Eu tenho uma classe chamada ConferenceTrack com uma propriedade de identidade chamada TrackId. Convenção de código primeiro procura por “ ID ” ou nome da classe + “ ID ” como uma propriedade de identidade a ser usado para EntityKey da entidade e a chave primária da tabela de banco de dados. Mas TrackId não couber esse padrão, portanto, tenho que informar o EF que esta é minha chave de identidade.

A nova classe código primeira ModelBuilder baseia-se o modelo de memória com base nas classes descritas anteriormente. Além disso, você pode definir configurações usando ModelBuilder. Eu sou capaz de especificar que a entidade ConferenceTrack deve usar a propriedade TrackId como sua chave com a seguinte configuração ModelBuilder:

modelBuilder.Entity<ConferenceTrack>().HasKey(
  ct => ct.TrackId);

ModelBuilder agora terão essas informações adicionais em consideração como é trabalhar fora do esquema de banco de dados e criar o modelo de memória.

Aplicando configurações mais logicamente

Isso é onde DbContext.OnModelCreating entra tão bem. Você pode colocar as configurações nesse método, de modo que poderá ser aplicados como o modelo que está sendo criado pelo DbContext:

protected override void OnModelCreating(
  ModelBuilder modelBuilder) { 
  modelBuilder.Entity<ConferenceTrack>().HasKey(
    ct => ct.TrackId); 
}

Outro novo recurso adicionado no CTP4 é uma maneira alternativa para aplicar configurações por meio de atributos nas classes. Essa técnica é chamada de dados de anotações. A mesma configuração pode ser obtida pela aplicação na anotação Key diretamente para a propriedade TrackId na classe ConferenceTrack:

[Key] 
public int TrackId { get; set; }

Certamente mais simples, no entanto, minha preferência pessoal é usar as configurações através de programação para que as classes não precisam ter nenhum conhecimento específico do EF neles.

Essa abordagem também significa que DbContext cuidará do cache do modelo, de modo ainda mais construir DbContexts o não incorrer custo de descoberta de modelo novamente.

Relações de obter o mais fácil

Uma das melhorias mais digno de nota para o código pela primeira vez é muito mais inteligente quanto ao fazendo pressuposições de classes. Embora haja vários aprimoramentos para as seguintes convenções, considero as convenções de relacionamento aprimorada afetaram o meu código mais.

Mesmo que as relações são definidas nas suas classes, nos CTPs anteriores era necessário fornecer informações de configuração para definir essas relações no modelo. Além disso, as configurações foram bem nem lógica. Agora código pela primeira vez pode interpretar corretamente a intenção de que a maioria dos relacionamentos definidos em classes. Em casos em que você precise ajustar o modelo com algumas configurações, a sintaxe é muito mais simples.

Minhas classes de domínio tem um número de relacionamentos definidos por meio de propriedades. Por exemplo, o ConferenceTrack tem esse relacionamento um-para-muitos:

public ICollection<Session> Sessions { get; set; }

Sessão tem a relação de conversar, bem como um muitos-para-muitos:

public ConferenceTrack ConferenceTrack { get; set; }
public ICollection<Speaker> Speakers { get; set; }

Usando minhas classes e configuração de um único (para definir o TrackId como chave para conferências), o construtor de modelo criados no banco de dados com todas as relações e heranças mostradas em do Figura 2.

Do modelo de construção de criação de estrutura de banco de dados, a Figura 2

Observe a tabela de Sessions_Speakers criada para o relacionamento muitos-para-muitos. Meu domínio tem uma classe de workshop que herda da sessão. Por padrão, o código pressupõe primeiro tabela por hierarquia de herança, para que ele criou uma coluna discriminatória na tabela de sessões. Posso usar uma configuração para alterar seu nome para IsWorkshop ou até mesmo especificar que ele deve criar uma tabela por tipo de herança em vez disso.

Planejar com antecedência para estes novos recursos

Forçando os novos recursos que você tem acesso antecipado a CTP4 podem ser uma fonte de frustração para os desenvolvedores que escrevem “ eu quero que isso agora! ” É verdade que esta é apenas uma visualização e não pode colocá-lo em produção hoje em dia, mas certamente brincar com esses bits se você for capaz de e forneça seus comentários à equipe EF para ajudar a torná-lo ainda melhor. Você pode começar a planejar com antecedência, como você usará código pela primeira vez e outros novos EF recursos em seus aplicativos futuros.

Julie Lerman é um MVP do Microsoft .net mentor e consultor de quem mora nas Montanhas de Vermont. Você pode encontrar a sua apresentação no acesso a dados e outros tópicos do Microsoft .net em grupos de usuários e conferências em todo o mundo. Blogs de Lerman em thedatafarm.com/blog de e é autor do livro altamente aclamado pacote, “ Programming Entity Framework ” (O’Reilly Media, 2009). Siga sua Twitter.com: julielermande .

Meus agradecimentos aos seguinte especialista técnico para revisar este artigo: Rowan Miller