[Resolvido] Ado.net Entity Framework

[xanburzum 169]

Quando deparamos sobre a quantidade de código que o desenvolvedor deve escrever para as diferentes representações de dados (por exemplo armazena objetos e relacionais) é claro que existe uma oportunidade de melhoria. Na verdade, há muitos cenários em que o framework pode capacitar um pedido de desenvolvedor para se concentrar nas necessidades da aplicação, por oposição às complexidades da ponte dados díspares representações.

A meta principal da próxima versão do ADO.NET é de elevar o nível de abstração de dados para efeitos de programação, ajudando assim a eliminar o fosso existente entre os dados de impedância e os modelos e linguagens que. Duas inovações que tornam possível este movimento são-Language Integrated Query e os ADO.NET Entity Framework. A Entidade Framework existe como uma nova parte da família de tecnologias ADO.NET. ADO.NET LINQ-á permitir o acesso aos dados muitos componentes: LINQ para SQL, LINQ para DataSet e LINQ para Entidades.

 

Onde queremos ir

 

Um ambiente ideal para a criação de aplicações empresariais devem permitir aos desenvolvedores descrever a lógica empresarial e o estado do problema que estão modelando com mínima ou nenhum " noise" proveniente da representação e da infra-estrutura subjacente de que ele suporta. As candidaturas deverão ser capazes de interagir com as lojas que mantêm o estado persistente do sistema em termos do domínio do problema, especialmente nos termos de um modelo conceitual domínio, completamente separada do esquema de lógica subjacente a loja.

Seria de esperar que os desenvolvedores poderão escrever algo como o código abaixo:

 

using(OrderTracking orderTracking = new OrderTracking()) {

var orders = from order in orderTracking.SalesOrders
where order.Status == " Enquanto se aguarda confirmação" &&
order.SalesPerson.State == "WA"
select order;

foreach(SalesOrder order in orders) {

// obter uma lista do objeto StockAppProduct 
// para usar na validação
List<StockAppProduct> products = new List<StockAppProduct>(
from orderLine in order.Lines
select new StockAppProduct {
ProductID = orderLine.Product.ID,
LocatorCode = ComputeLocatorCode(orderLine.Product)
}
);

/ / Certifique-se de todos os produtos para este fim 
/ / Estão em estoque através das ações de gestão Sistema if(StockApp.CheckAvailability(products)) {

order.Status = "Shippable";
}
}

orderTracking.SaveChanges();
}

Há dois elementos que são importantes para destacar no código acima:

 

• Não construções artificiais. É comum ver aplicações que necessitam de se adaptar às peculiaridades da loja no esquema subjacente. Por exemplo, as aplicações construídas em cima de bancos de dados relacionais muitas vezes têm que fazer uso extensivo, a fim de navegar através das relações. No código acima, em contrapartida, a "forma" dos dados segue as abstrações do problema a ser modelado; existem "ordens", que "as linhas de pedido" e que estão relacionados com uma "pessoa de vendas".

• Sem plumbing. O código de dados é muito intenso, ainda não há conexão de objetos de dados, nenhuma língua externa como SQL query para formulação, nenhum parâmetro obrigatório, sem configuração embutido em código. Neste sentido, pode-se dizer que esse código é "pura lógica empresarial".

Esta é a classe de expressividade e abstração nível que ADO.NET e, em especial a Entity Framework LINQ e trabalhando em conjunto, traz para desenvolvimento de aplicativos.

 

O ADO.NET Entity Framework: Modelagem para o nível certo de abstração

 

Cada negócio tem aplicação, explícita ou implicitamente, um modelo conceitual de dados que descreve os diversos elementos do problema, bem como cada elemento da estrutura, as relações entre cada elemento, as suas limitações, e assim por diante.

Uma vez que atualmente a maioria dos pedidos são escritos em cima de bancos de dados relacionais, mais cedo ou mais tarde eles terão de lidar com os dados representados em um formato relacional. Mesmo que houvesse um maior nível de modelo conceitual utilizado durante a concepção, o modelo que normalmente não é diretamente "executável", pelo que deverá ser traduzida em um formato relacional e aplicada a um esquema lógico de dados e para o código da aplicação.

Enquanto o modelo relacional tem sido extremamente eficaz nas últimas décadas, é um modelo que visa atingir um nível de abstração que muitas vezes não é adequado para modelar a maioria das empresas aplicativos criados utilizando modernas de desenvolvimento de ambientes.

 

Vamos usar um exemplo para ilustrar este ponto. Aqui está um fragmento de uma variação do modelo de banco de dados AdventureWorks que está incluído no Microsoft SQL Server 2005:

 

 

Figure 1

Se estivéssemos construindo uma aplicação de recursos humanos no topo desta base de dados e em algum momento quis encontrar todos os empregados a tempo inteiro que foram contratados durante o ano de 2008 e lista os seus nomes e títulos, não teríamos que escrever a seguinte consulta SQL :

 

SELECT c.FirstName, e.Title
FROM Employee e
INNER JOIN Contact c ON e.EmployeeID = c.ContactID
WHERE e.SalariedFlag = 1 AND e.HireDate >= '2008-01-01'

 

• Enquanto este pedido específico trata apenas de "funcionários", ele ainda tem de lidar com o fato de que o esquema de dados lógico é normalizada pelo que o contato de informação dos trabalhadores, por exemplo. Enquanto isto não se refere à aplicação, desenvolvedores continuariam a ter de incluir esse conhecimento em todas as consultas no requerimento que lidar com os empregados. Em geral, as aplicações não podem escolher o esquema lógico de dados (por exemplo, aplicações departamentais que exponha os dados do sistema central de dados da empresa), bem como o conhecimento de como fazer o mapa de esquema lógico para o "adequado" dos dados que o aplicação requer é implicitamente expressas através de consultas ao longo de todo o código.

• Este exemplo trata apenas de trabalhadores a tempo inteiro, por isso não se deve idealmente ver qualquer outro tipo de trabalhadores. No entanto, uma vez que este é um banco de dados compartilhado, todos os empregados estão na tabela de empregados, e eles são classificados através da coluna "SalariedFlag"; isso, novamente, significa que cada consulta emitida por esta aplicação irá incorporar o conhecimento de como distinguir uma tipo de empregado a partir do outro. Idealmente, se o pedido se trata de um subconjunto dos dados, o sistema deverá apenas apresentar esse subconjunto dos dados, e os desenvolvedores devem ser capazes de indicam que ele é adequado subconjunto.

 

Os problemas referidos anteriormente estão relacionados ao fato de que a base de dados lógico esquema não é o direito de ver os dados para uma determinada aplicação. Repare que, neste caso particular, uma visão mais apropriada poderia ser criado usando os mesmos conceitos utilizados pelo esquema existente (isto é, tabelas e colunas que existem no modelo relacional). Há outras questões que surgem quando edifício data-centric aplicações que não são facilmente modeladas utilizando os construtores fornecidos pelo modelo relacional sozinho.

Digamos que um outro pedido, desta vez, o sistema de vendas, também é construída em cima de um mesmo banco de dados. Usando a mesma lógica do esquema usamos no exemplo anterior, teremos que usar a seguinte consulta para obter todas as vendas de pessoas que têm encomendas de vendas superiores a US $ 200.000:

 

SELECT SalesPersonID, FirstName, LastName, HireDate
FROM SalesPerson sp
INNER JOIN Employee e ON sp.SalesPersonID = e.EmployeeID
INNER JOIN Contact c ON e.EmployeeID = c.ContactID
INNER JOIN SalesOrder o ON sp.SalesPersonID = o.SalesPersonID
WHERE e.SalariedFlag = 1 AND o.TotalDue > 200000

 

Novamente, a consulta é bastante complicada em comparação com o relativamente simples questão de que estamos solicitando ao nível conceptual. As razões para tal complexidade incluem:

 

• Novamente, a lógica do esquema de dados é demasiado fragmentada, e que introduz complexidade que o aplicativo não necessitadas. Neste exemplo, a aplicação é provavelmente apenas interessados em "pessoas de vendas" e "ordens de vendas", o fato de as vendas "está distribuído por 3 tabelas é desinteressante, mas ainda tem conhecimento de que o código da aplicação tem de ter.

 

• Conceitualmente, sabemos que uma venda está associada a zero ou mais ordens de venda, no entanto, pesquisas têm de ser formuladas de uma forma que não pode alavancar esse conhecimento, em vez disso, essa consulta tem que fazer um join explícito para caminhar através desta associação.

Além das questões apontadas acima, tanto queries apresentar outro problema interessante: eles retornam informações sobre empregados e vendas, respectivamente. No entanto, não se pode pedir a um sistema de "empregado" ou uma "pessoa de vendas". O sistema não tem conhecimento do que isso significa. Todos os valores devolvidos a partir de Projeções queries que são simplesmente copiar alguns dos valores na linha da tabela para o resultado-set, perdendo qualquer relação com a fonte de dados.

 

Isto significa que não existe um entendimento comum em todo o código da aplicação sobre os conceitos fundamentais, como a aplicação empregado, ou ele pode fazer valer adequadamente constrangimentos associados a esse conceito. Além disso, uma vez que os resultados são apenas projeções, a fonte de informação que descreve os dados vieram de onde está perdido, exigindo que os desenvolvedores dizem explicitamente como o sistema de inserções, atualizações e exclusões deve ser feito usando comandos SQL específicos.

 

As questões discutidas acabamos de cair em duas classes principais:

 

• Aquela relacionada ao fato de que o lógico (relacional) modelo e respectivas infra-estruturas não podem alavancar o conhecimento conceitual domínio da aplicação de dados modelo, não é capaz de compreender entidades empresariais, as suas relações entre si, ou as suas limitações.

• Os relacionados com o problema prático que têm bases lógicas de esquemas que normalmente não correspondem a candidatura; aqueles esquemas muitas vezes não pode ser adaptado porque são partilhadas por muitos aplicativos ou, devido à falta de requisitos funcionais, tais como operações de apropriação de dados, desempenho ou segurança.

Os problemas descritos acima são muitos comuns na maior parte dos dados Centrado em aplicativos empresariais. Para resolver estas questões introduz o ADO.NET Entity Framework, que consiste em um modelo de dados e um conjunto de design em tempo e em tempo de execução de serviços que permitem que desenvolvedores descrever a aplicação de dados e interagir com ele em um "concetual" nível de abstração que é adequado para aplicações de negócios, e que ajuda a isolar a lógica subjacente a aplicação de esquemas de dados.

 

Modelagem Conceitual de Dados ao Nível de Abstração: O Modelo de Dados Entidade

 

A fim de resolver o primeiro problema identificado na seção anterior o que precisamos é uma maneira de descrever a estrutura de dados (o esquema) que usa o constrói mais alto nível.

O Modelo de Dados Entidade ou EDM um modelo de dados Entidade-Relacionamento. Os conceitos-chave introduzidos pela EDM são:

 

• Entidade: entidades que são instâncias de Entity Types (por exemplo: Colaborador, SalesOrder), que são ricamente estruturado registros com uma chave. Entidades são agrupados em Entidade-Sets.

 

• Relação: relacionamentos associar entidades, e que são instâncias de Relacionamento Types (por exemplo, SalesOrder pelo vendedor). Relacionamentos são agrupados em Relação-Sets.

 

A introdução de um conceito explícito da Entidade e Relacionamento permite que desenvolvedores de ser muito mais explícito ao descrever esquemas. Para além destes conceitos fundamentais, a EDM suporta várias construções que alargam ainda mais a sua expressividade. Por exemplo:

 

• Herança: entidade tipos podem ser definidos para que eles herdarão a partir de outros tipos (por exemplo: O empregado que poderia herdar a partir de Contato). Este tipo de herança é estritamente estrutural, o que significa que não existe um “comportamento” herdado como acontece em orientados ao objeto, linguagens de programação. O que está em herdada é a estrutura de base do tipo de entidade, além de herdar a sua estrutura, uma das instâncias derivadas satisfazer o tipo de entidade "é um" relacionamento quando testados contra a base tipo de entidade.

 

• Complexo tipos: para além das habituais tipos escalar apoiado pela maioria dos bancos de dados, a EDM apoia a definição de tipos complexos e sua utilização como membros da entidade tipos. Por exemplo, você poderia definir um endereço que tem complexo StreetAddress, propriedades Cidade e Estado e, em seguida, adicione uma propriedade do tipo Morada de contacto para o tipo de entidade.

Com todas estas novas ferramentas, nós podemos definir o esquema lógico que temos utilizado na secção anterior utiliza um modelo conceitual:

 

 

Figure 2

Este esquema possui os seguintes elementos:

 

• Três tipos de entidade: SalesPerson, SalesOrder e StoreSalesOrder. Note que StoreSalesOrder "é um" SalesOrder (em herda dos SalesOrder), com a característica especial de ter informações fiscais.

• A relação entre a entidade SalesPerson SalesOrder e os tipos

• Dois conjuntos de entidade: SalesOrders e SalesPerson; nota que a entidade SalesOrders-set pode ter ocorrências de ambos os tipos SalesOrder e StoreSalesOrder entidade.

Este novo modelo é muito mais próximo do ponto de vista de que uma venda para a sua aplicação possa utilizar loja. Algumas coisas importantes a observar incluem o fato de que as SalesPerson já não estão espalhados por várias tabelas, eles estão em uma única entidade-set vez, também, não há primárias / chaves estrangeiras no esquema, em vez disso, um relacionamento é expressamente declarada a existir no modelo.

Para fornecer um exemplo concreto, na seção anterior que precisávamos de um 3-way para acessar os nomes das pessoas que as vendas em uma consulta, algo como:

 

SELECT sp.FirstName, sp.LastName, sp.HireDate
FROM SalesPerson sp
INNER JOIN Employee e ON sp.SalesPersonID = e.EmployeeID
INNER JOIN Contact c ON e.EmployeeID = c.ContactID
WHERE e.SalariedFlag = 1 AND e.HireDate >= '2008-01-01'

 

Agora que temos um nível mais alto de modelo EDM, poderíamos escrever esta mesma consulta contra um conjunto de SalesPeople:

SELECT sp.FirstName, sp.LastName, sp.HireDate
FROM AdventureWorks.AdventureWorksDB.SalesPeople AS sp
WHERE e.HireDate >= '2008-01-01'

 

Isso é significativamente mais simples e tem exatamente a mesma semântica, com a possibilidade acrescida de que as informações sobre como construir a visão adequada dos dados para esta aplicação é agora expressa declaratively em um artefato externo (EDM o esquema de mapeamento e que iremos discutir posteriores).

ADO.NET inclui ferramentas que são utilizadas para projetar estes esquemas. A saída da ferramenta é um arquivo XML que descreve o esquema conceitual de esquema utilizando Description Language ou a SDL. Agora, se esse novo esquema conceitual é diferente do esquema lógico no próprio banco de dados, como é que o sistema sabe como ir para frente e para trás entre os esquemas? A resposta é "mapeamento".

 

Trazendo dados em um EDM Modelo: Mapeamento

 

A EDM é um modelo conceitual de dados que podem ser usados para modelar os dados de um determinado domínio. No entanto, em algum momento os dados necessitam de ser armazenado em um verdadeiro banco de dados, normalmente um banco de dados relacional.

A fim de fornecer um mecanismo para armazenagem de dados modelado utilizando a EDM em bancos de dados relacionais, o ADO.NET Entity Framework alberga um poderoso cliente-visualizações infra-estrutura concebida para gerir as transformações entre a base de dados lógico que o esquema relacional presente na loja e conceitual da EDM esquema utilizado pelo aplicativo.

Para além da EDM esquema, o sistema tem como entrada um mapeamento especificação; este mapeamento especificação é produzido pelas ferramentas de mapeamento e também é um arquivo XML.

 

Para continuar com o exemplo, se quisermos fazer o levantamento, a base de dados lógico que nós esquema utilizado no início desta secção para a EDM esquema conceitual da seção anterior, tínhamos fazer algo parecido com isto:

 

A Figura 3

 

Quando a ferramenta de mapeamento é usado para criar uma cartografia conceitual lógica, ele produz um arquivo XML que pode ser consumida pelos componentes em tempo de execução do ADO.NET Entity Framework. Felizmente, as ferramentas vão tornar desnecessário para a grande maioria dos utilizadores têm de compreender ou para lidar com esses arquivos XML.

Além de fornecer apoio para revestimento de esquemas como EDM schemas, o client-views na infra-estrutura ADO.NET tem outras vantagens. No início desta seção, discutimos a forma como os bancos de dados com esquemas pertence agora pela aplicação o desenvolvedor pode introduzir complexidade no código do aplicativo. Ao usar o client-views, a complexidade trazidos pelos esquemas externos lógico pode ser interrompida antes que ele atinja o código da aplicação; views podem ser criados para realizar qualquer re-configuração dos dados necessários para a aplicação. Dessa forma o pedido tenha uma visão da pessoa que faz sentido para o problema espaço que ela aborda. Isso é útil independentemente de novas construções EDM são utilizados no modelo resultante.

 

Uma pergunta óbvia neste momento seria por isso que não basta utilizar tradicionais database views para esta. Embora muitos database views podem em resumo dos mapeamentos, muitas vezes essa solução não vai funcionar para processar por diversos motivos: (a) muitas das opiniões são simplesmente demasiado complexa para ser gerados e mantidos pelos promotores de uma forma rentável, mesmo para alguns mapeamentos simples conceitual para lógica, ( as opiniões que têm a propriedade de ser atualizada automaticamente na loja são limitadas, e © às bases de dados sobre-core em sistemas de médias e grandes empresas são utilizadas por muitas centrais e aplicações departamentais, e com cada pedido criar vários client-views em banco de dados podem poluir o banco de dados de esquema e criar manutenção significativa carga de trabalho dos administradores do banco de dados. Além disso, database views estão limitadas a expressividade do modelo relacional e, normalmente, a falta de alguns dos mais conceitos do mundo real da Entidade Modelo de Dados, tais como herança e tipos complexos.

ADO.NET client-views inteiramente posições sobre o cliente, de forma cada aplicação desenvolvedor pode criar visualizações que adaptar os dados de uma forma que faça sentido para cada aplicação específica sem afetar o próprio banco de dados ou outros aplicativos. A classe de updatable das entidades suportado no Framework é muito mais amplo do que os suportados por qualquer store relacional.

Pavimentação da EDM e mapeamento para o ADO.NET API: O Mapeamento Provider

A EDM e mapeamento conceitos parecem ser bastante abstrata num primeiro momento, portanto, neste momento, alguém poderia pensar como é que eles são concretamente na API ADO.NET.

Optou-se por introduzir um novo provedor de acesso de dados para o ADO.NET chamado "mapeamento provedor". Assim como um fornecedor regular se conecta a uma loja prevê a aplicação, a fim de armazenar os dados em seu esquema lógico, o mapeamento se conecta a um provedor EDM modelo conceitual e fornece a aplicação com uma visão conceitual dos dados.

O mapeamento é dada a EDM provedor de esquema e as informações de mapeamento, de forma que ele possa usar internamente a infra-estrutura para tradução de mapeamento entre os esquemas conceituais e lógico.

Assim, por exemplo, para executar uma consulta a EDM modelo que encontra os nomes e as datas de locação com opção de venda contratar pessoas depois de um determinado momento, o ADO.NET código seria:

 

using(MapConnection con = new 
MapConnection(Settings.Default.AdventureWorks)) {
con.Open();

MapCommand cmd = con.CreateCommand();
cmd.CommandText =
"SELECT sp.FirstName, sp.LastName, sp.HireDate " +
"FROM AdventureWorks.AdventureWorksDB.SalesPeople AS sp " +
"WHERE sp.HireDate > @date";
cmd.Parameters.AddWithValue("date", hireDate);

DbDataReader r = cmd.ExecuteReader();
while(r.Read()) {
Console.WriteLine("{0}\t{1}", r["FirstName"], r["LastName"]);
}
}

Note que o padrão deve ser muito familiar aos desenvolvedores ADO.NET, olha só como o código ADO.NET 2,0, com a única diferença de que ele usa um provedor diferente.

O provedor irá utilizar o mapeamento de esquema EDM e de cartografia / visualizar informações e traduzir a partir do modelo conceitual. Em seguida, ele será utilizar um provedor ADO.NET regulares para falar com o banco de dados subjacente (por exemplo, seria utilizar System.Data.SqlClient para conversar com uma base de dados SQL Server).

 

Consultando um modelo EDM: entidade SQL

Quando um aplicativo usa um modelo EDM do provedor de mapeamento para acessá-la, ela já não se conecta diretamente a um banco de dados ou vê qualquer banco de dados específicos de construção; todo o aplicativo funciona em termos do nível mais alto do modelo EDM.

Isso significa que você não pode mais usar o database query language nativo, não apenas o banco de dados não irá compreender a EDM modelo, mas também dados atual mas também dados database query languages não têm os construtores necessários para lidar com os elementos introduzidos pela EDM como a herança, relações complexas-tipo, etc

 

A fim de permitir a consulta a modelos EDM, o ADO.NET Entity-framework introduz uma consulta que a para trabalhar com a EDM que pode alavancar a plena expressividade do modelo de dados da entidade. A linguagem SQL é chamada Entidade familiar e que deveria olhar para todos os desenvolvedores que têm usado algum dialeto SQL. Entidade SQL fornece o Framework com uma Entidade query de capacidade dinâmica, onde podem ser estaticamente consultas formuladas pelo tempo design ou construídas em tempo de execução no contexto da tarde vinculada aplicações.

Por exemplo, esta é uma Entidade consulta SQL válida a partir do exemplo anterior:

 

SELECT sp.FirstName, sp.LastName, sp.HireDate
FROM AdventureWorks.AdventureWorksDB.SalesPeople AS sp
WHERE sp.HireDate > @date

A estrutura geral de uma entidade é a habitual consulta SQL SELECT-FROM-WHEREL. Para além dos elementos básicos desta Entidade SQL introduz vários conceitos para permitir que desenvolvedores alavancar a expressividade dos modelos conceituais EDM, que se segue é uma descrição dos principais conceitos adicionais trazidos para o cenário por Entity SQL:

 

Lidar com as entidades.

 

Esquemas conceituais EDM são projetados em torno de entidades. Conceitos empresariais refletem-se diretamente no tipos EDM de entidades cujas ocorrências são armazenadas na entity-sets. Da mesma maneira buscas no mundo relacional são formuladas contra tabelas, pesquisas EDM são formuladas contra a entity -sets. Então, o ponto de partida para uma consulta é um conjunto de entidades provenientes de um ou mais conjuntos de entidade.

Dependendo das suas necessidades em cada cenário específico, você pode escolher o projeto para preservar os valores individuais ou toda entidade. Preservar toda a entidade é interessante quando você deseja que o sistema ajude-o com serviços que são construídas em torno de entidades. Por exemplo, graças aos metadados fornecidos no esquema EDM e mapeamento especificação, o ADO.NET Entity Framework sabe como as atualizações refletem a entidades de volta na loja sem que o usuário tenha de prestar comandos INSERT, UPDATE e DELETE como o ADO.NET DataAdapter tem tradicionalmente exigido.

Consultas com projeção olhar parece muito com a regular consultas SQL, com a ressalva de que a tabela aliases são obrigatórios:

 

SELECT sp.FirstName, sp.LastName, sp.HireDate
FROM AdventureWorks.AdventureWorksDB.SalesPeople AS sp
WHERE sp.HireDate > @date


SELECT VALUE sp
FROM AdventureWorks.AdventureWorksDB.SalesPeople AS sp
WHERE sp.HireDate > @date

 

O "VALOR" modificado indica que o sistema que deveria produzir um conjunto de valores, em conjunto, o resultado representa qualquer uma das entidades ou instâncias escalares; irá preservar os resultados de todos os metadados necessários para descrever integralmente os valores, incluindo a maneira de extrair chaves primárias para entidades, onde fez a entidade de origem, etc

A partir da perspectiva result-set, quando uma entidade se projeta fora do objeto DataReader resultante tem uma coluna de nível superior para cada membro da entidade tipo (por isso ela efetivamente se parece com todas as colunas foram projetados na consulta, mas com o metadados adicionais sobre a diferença de que a entidade está disponível).

Relação de navegação. Além de entidades, o outro elemento-chave da EDM é um conceito expresso por relações de associação, uma vez que o sistema sabe sobre as relações entre as entidades, a consulta pode ser utilizada a linguagem explícita para navegar nesses relacionamentos sem ter que usar construções como a junta .

Por exemplo, usamos esta consulta antes de encontrar pessoas com ordens de vendas de mais de um certo valor:

 

SELECT SalesPersonID, FirstName, LastName, HireDate
FROM SalesPerson sp
INNER JOIN Employee e ON sp.SalesPersonID = e.EmployeeID
INNER JOIN Contact c ON e.EmployeeID = c.ContactID
INNER JOIN SalesOrder o ON sp.SalesPersonID = o.SalesPersonID
WHERE e.SalariedFlag = 1 AND o.TotalDue > 200000

 

A complexidade desta consulta é proveniente de o fato de que o vendedor está distribuído por tabelas e a navegação do vendedor a fim de vendas precisa ser feito indiretamente, através de uma join.

Usando o novo esquema conceitual EDM nós definido anteriormente, podemos formular a consulta desta forma:

 

SELECT VALUE sp
FROM AdventureWorks.AdventureWorksDB.SalesPeople AS sp
WHERE EXISTS(
SELECT VALUE o 
FROM NAVIGATE(p, AdventureWorks.SalesPerson_Order) AS o
WHERE o.TotalDue > 200000)

 

O operador " NAVIGATE " permite uma consulta para cruzar uma relação explícita, o aplicativo não precisa saber como é a relação mantida ou usar métodos indiretos, como a junta de usá-la.

Herança apoio. Desde a EDM suporta tipos de herança para a entidade, a consulta idioma tem de permitir que os usuários formular consultas que olhar para a herança hierarquia de tipos.

Por exemplo, o nosso esquema conceitual EDM tem um tipo de entidade SalesOrder, e um subtipo StoreSalesOrder que possui algumas características específicas. Uma vez que todos os StoreSalesOrder "é um" SalesOrder, uma consulta contra a entidade SalesOrders-set retornaria um resultado polimórficas-set contendo as duas instâncias do SalesOrder e StoreSalesOrder tipos:

SELECT VALUE o

FROM AdventureWorks.AdventureWorksDB.SalesOrders AS o

 

Se quiséssemos apenas as vendas das ordens de lojas, tínhamos o perguntar por explicitamente que o sistema de alavancar o tipo de hierarquia:

 

SELECT VALUE o
FROM AdventureWorks.AdventureWorksDB.SalesOrders AS o
WHERE o IS OF (AdventureWorks.StoreSalesOrder)

 

Aqui, o operador ESTÁ DE verifica se uma expressão ( "o" neste caso) é um exemplo do tipo especificado no parêntese.

Lições aprendidas. Para além das várias extensões em Entity SQL concebida para proporcionar uma experiência de primeira classe query contra EDM schemas, Entity SQL incorpora diversas melhorias que vêm de experiência com o mais tradicional do SQL Dialetos.

 

Por exemplo, a Entidade nas expressões SQL pode produzir escalares ou coleções, e coleções de primeira classe são construções que podem ser exibidos na maioria dos contextos expressão, combináveis e torná-los plenamente. Por exemplo, uma coleção pode ir na cláusula FROM e atuar como a fonte para uma consulta, ou ele pode ir na lista SELECT, o que resultará em uma das colunas do resultado result-set de uma coleção em vez de um tipo escalar.