Qual é a maneira mais simples de converter um provedor de odata de serviços de dados da WCF para a API da Web?

Question

Atualmente, estou analisando a viabilidade de converter nosso atual provedor de Odata de Serviços de Dados do WCF em API ODATA da Web.

Estou um pouco confuso com a implementação do Odata para API da Web. Com os serviços de dados da WCF, ele fica sobre o modelo de entidade ADO.NET, que expõe um monte de tabelas do back -end do servidor SQL, ou seja, você dá a WCFDS o modelo ADO para gerar e, em seguida, você tem acesso a todas as tabelas através do padrão Sintaxe Odata.

Com a API da Web de todas as leituras até agora, criamos um controlador ou ações separadas para cada tabela/objeto que queremos expor? Estou esquecendo de algo? Existe apenas uma maneira de o controlador da API da Web ODATA pode apenas expor todo o modelo do modelo de dados ADO? Ter que criar uma ação para cada tabela seria uma bagunça e um exagero.

Atualmente, se precisarmos adicionar uma tabela, apenas mapeamos no EDMX e WCFDS o expõem automaticamente, pois é mapeado para todo o contexto do modelo.

Answer 1

Gerando o (s) modelo (s)

Você pode:

• Use o Construtor de modelos de convenções da API da web asp.net. Isso gera um modelo diferente do que o próprio modelo de convenção da EF produz: um edmlib IEdmModel. Ver essa questão embora se você estiver usando o modelo primeiro ou o banco de dados. Esse método parece realmente atrasado, e é, mas funciona principalmente.
• Serialize o modelo de EF e reconstruí -lo como um IEdmModel (Vejo essa questão). Novamente, isso é realmente ineficiente. Se você estiver usando o Model-primeiro ou o banco de dados, você deseja apenas desserializar o arquivo EDMX para construir o IEdmModel. Ele ainda produz um modelo diferente internamente, mas pelo menos o CDSL é um formato mais estável do que as convenções de código CLR; portanto, você provavelmente terá menos surpresas do que você obteria ao usar dois construtores de modelos baseados em convenções diferentes.

A razão para isso é que as extensões do ASP.NET Web API ODATA usam o EDMLIB, enquanto a EF usa seu próprio código, e Não há plano para fazê -los trabalhar juntos. Talvez você encontre este discurso retórico Útil se você estiver curioso.

Trabalhando na API

Depois de gerar o modelo a partir de uma fonte exclusiva (para que você possa trabalhar em seu modelo a partir de um único local), você realmente precisará criar um controlador por entidade, basicamente. O objetivo da API da Web não é criar as coisas automaticamente, mas oferecer flexibilidade ao desenvolvedor. o EntitySetController Ajuda a reduzir a redundância, mas não oferecerá tudo fora da caixa.

Dando um passo para trás

No discurso mencionado acima, também falo sobre a diferença entre um camada de serviço API e a camada de dados API. A API da Web ASP.NET é mais adequada para serviços, enquanto o Odata torna os serviços estranhos. Por outro lado, o OData facilita o acesso dos dados (sendo essencialmente como um SQL repousante) e, em virtude de estar diretamente anexado ao modelo de dados, pode automatizar muitas coisas como você viu com os serviços de dados do WCF. API da Web ASP.NET com extensões ODATA está no meio, e seu valor não é universalmente acordado (usando certos bits de sintaxe de Odata Uri nas APIs de serviço é certamente útil).

Não fique muito empolgado com o burburinho recente em torno da API da Web ASP.NET, os serviços de dados de TI e WCF são bestas muito diferentes e são executadas em diferentes camadas em seu design. De fato, em uma arquitetura de várias camadas, você pode muito bem ver uma API de serviço construída usando a API da Web ASP.NET sentada em cima de uma API ODATA construída usando o WCF Data Services.

Meu conselho é pensar cuidadosamente sobre o que você está tentando construir e, dependendo da resposta, escolha API da Web ASP.NET e abraça o fato de que a API que você expõe será muito diferente de uma API ODATA centrada em dados, ou Stick com serviços de dados da WCF.

Um possível plano

Você pode encontrar muito material na Web sobre as APIs da camada de serviço na Web pesquisando termos como "API não CRUD Web/RESTful/Hypermedia" ou comparando produtos como o ServiceStack, que defendem menos APIs orientadas a dados.

Se você ainda não tem certeza sobre a natureza do seu projeto, protótipo.

• Se você acabar com um monte de controladores essencialmente idênticos com a API da Web, cada um mapeado para exatamente uma entidade, sua API será fortemente orientada a dados. Vá com serviços de dados WCF.
• Se você acabar com muitas ações de Odata e entidades desajeitadas com serviços de dados WCF, precisará de mais lógica de domínio no lado do servidor da API e a orientação de dados não oferece o suficiente. Vá com API da web. Uma boa regra prática aqui é tratar as ações dos Odata, assim como você trata os procedimentos armazenados em um SQL DBMS. Na verdade, trate qualquer servidor ODATA como um DBMS, porque é isso que eles são. Se você não colocá -lo atrás de uma interface SQL, não o coloque atrás de uma interface Odata.

Atualização Importante)

Foi anunciado em 27 de março de 2014 que os serviços de dados da WCF seriam interrompido pela Microsoft a favor da API da Web ASP.NET. Para lidar com os casos de uso da "camada de dados" que eu expus aqui, a Microsoft disse que planeja estender a API da Web do ASP.NET. Algum comunidade esforços também estão em andamento. Os Serviços de Dados da WCF também serão de origem aberta em algum momento, por isso não é impossível que um novo mantenedor aquisite, embora seja incerto.