Onde estão os serviços WCF e ADO.Net Data?

Question

Estou um pouco confuso sobre o ADO.Net Data Services.

Destina-se apenas à criação de serviços web RESTful?Eu sei que o WCF começou no mundo SOAP, mas agora ouvi dizer que ele tem um bom suporte para REST.O mesmo vale para os serviços de dados ADO.Net, onde você pode fazê-lo funcionar em um modelo RPC se não puder ver tudo a partir de uma visão orientada a recursos.

Pelo menos pelas demonstrações que vi recentemente, parece que o ADO.Net Data Services é construído na pilha WCF no servidor.Por favor corrija-me se eu estiver errado.

Não pretendo iniciar um debate REST vs SOAP, mas acho que as coisas não estão mais tão claras.

Alguma sugestão ou orientação sobre o que usar e onde?

Answer 1

Na minha opinião, os serviços de dados ADO.Net servem para criar serviços tranquilos que estão intimamente alinhados com o seu modelo de domínio, ou seja, os próprios modelos são publicados, em vez de dizer alguma forma de DTO, etc.

Usá-lo para serviços de estilo RPC parece uma má opção, embora, infelizmente, até mesmo alguns recursos muito básicos, como ser capaz de realizar contagens filtradas, etc.não estão disponíveis, o que muitas vezes significa que você acabará usando algum RPC apenas para atender aos requisitos de seus clientes, ou seja,para que você possa exibir uma grade paginada etc.

O WCF 3.5 pré-SP1 era uma plataforma RESTful bastante fraca, com o SP1 as coisas melhoraram nos modelos Uri e com a disponibilidade do suporte ATOMPub, de modo que está se tornando mais capaz, mas eles realmente não fornecem nenhuma solução elegante para suporte, digamos JSON , XML, ATOM ou até mesmo algo mais esotérico como carga útil como CSV simultaneamente, sem precisar fazer uso de reescrita de URL e extensão diferente, mudança de nome de método etc.- em vez de apenas selecionar um serializador/desserializador com base nos cabeçalhos da solicitação.

Com o WCF ainda é difícil criar serviços que funcionem de uma forma mais natural e tranquila, ou seja,onde os recursos incluem URLs, e você pode fazer a transição de estado navegando por eles - é um pouco desajeitado - os serviços de dados ADO.Net fazem isso muito bem com seu suporte ao AtomPub.

Minha recomendação seria usar serviços da web onde eles são naturalmente serviços e fortes limites de serviço sendo aplicados, usar serviços ADO.Net Data para clientes ricos em estilo da web (sites, ajax, silverlight) onde a capacidade de composição das consultas de URL pode salvar um muito encanamento e seu modelo de domínio é bastante básico ...e implemente sua própria camada REST (talvez usando uma estrutura MVC como ponto de partida) se precisar de controle total sobre as informações, ou seja,se você estiver publicando uma API para outros desenvolvedores consumirem em uma plataforma social, etc.

Meu 2ø vale a pena!

Answer 2

Usar a ligação restante do WCF é muito válido ao trabalhar com código que não interage com um banco de dados.Os verbos HTTP nem sempre precisam ir contra um provedor de dados.

Answer 3

Na verdade, existem opções para filtrar e pular para obter o recurso de curtida de página, entre outros.

Veja aqui: