Argumentos do uso do WCF/ODATA como camada de acesso em vez de EF/L2S/NHIBERNATE diretamente

Question

Desenvolvemos principalmente tráfego baixo, mas aplicativos da Web altamente especializados. Normalmente, usamos L2s, EF ou Nibernate como camada de acesso e depois joga o ASP.NET MVC e no qual para operações normais de CRUD, consultemos diretamente a isamento/datacontext, mas para funções mais avançadas/efeitos colaterais, colocamos em algum tipo de camada de serviço.

Agora, pensei em publicar os dados através do ODATA (WCF Data Service) e consultar isso dos controladores (ou mesmo do jQuery quando o mecanismo de modelo A Good aparecer) e publicar as operações de serviço por meio de um serviço WCF (ou como métodos personalizados no serviço de dados do WCF?). Que vantagens/desvantagens essa arquitetura representa?

Eu ganho algo, exceto maior complexidade e latência? Melhores separações de preocupações (ou é apenas uma ilusão)?

Editar:Pode ser uma boa ideia criar uma solução completa acionada pelo AJAX com por exemplo. Serviços WCF RIA? Ou um solta muita flexibilidade? Parece que você pode despachar completamente suas opiniões da sua lógica, então, um deve ser capaz de escrever HTML puro, nem mesmo um MVC do ASP.NET deve ser necessário? Mas acho que há muitos problemas novos?

Answer 1

Como o TomTom menciona, você não deseja pagar o custo do loopback pelo Odata quando dentro de um processo. Se você tiver linha de visão direta para o seu banco de dados e é o banco de dados do seu próprio aplicativo, não há razão para colocar os serviços de dados da WCF no meio. Eu continuaria usando uma das outras opções que você mencionou (L2S, EF, Nibernate).

Agora, se você precisar expor dados sobre o seu terminal HTTP para que outros aplicativos consumam, ou mesmo para o seu próprio aplicativo, se você tiver algum código jQuery no cliente que precisa acessar dados do servidor, então um endpoint do OData pode ajudar e O WCF Data Services é a maneira mais simples de criar uma.

Answer 2

Não faça isso. Desculpe, mas esta é uma abordagem estúpida de engenharia demais. Você está em um processo e insiste em executar uma conexão de rede e codificar todos os dados que passam para XML e retornam, além de executá -los em uma conexão HTTP com semântica de consulta limitada? Não diga a ninguém que você tentou.

A separação de preocupação é uma ilusão aqui - você substitui um modelo de domínio altamente otimizado por uma camada de dados simplificada.

Dito isto: eu amo Odata - ótimo. Mas não é uma tecnologia de programa, é uma tecnologia de front -end, como o ASP.NET MVC - apenas não para o usuário final, mas para outro programa integrar seus dados. Ele deve ser usado em cenários semelhantes e, ao expor os dados sobre as fronteiras de confiança (Silverlight - por exemplo - é uma borda de confiança, pois as solicitações podem ser falsificadas).

Não é otimizado para substituir em camadas de tempo de execução de alto aplicativo de processo, como o Nibernate.

Answer 3

Tomtom tem muitos votos e, embora não esteja errado, ele também não está certo, apesar de seu tom persuasivo.

Nesse caso, o OP parece estar escrevendo um aplicativo de estilo LOB Intranet que provavelmente só deve ser impedido por um serviço OData imitando o banco de dados subjacente, mas e se ele não estivesse imitando o banco de dados subjacente?

Se ele estivesse construindo um aplicativo com base em várias fontes de dados futuras ou desconhecidas, a camada de serviços poderá unificar, apresentar, simplificar e agregar esses serviços, mesmo que uma grande proporção de consultas eventualmente volte a um servidor SQL na próxima sala.

Da mesma forma, se você estiver construindo uma aplicação de escala maciça e, em escala, quero dizer milhões de usuários que esperam esperar alguns segundos entre as ações, e não milhões de negociações de FX por hora e, em seguida, colocar uma camada de serviços entre o seu aplicativo, os dados são um padrão comum. A escalabilidade da Internet é baseada em muitos pequenos servidores HTTP e na infraestrutura de cache inter.

Na vida real, as mesmas consultas são executadas inúmeras vezes, as pessoas atualizam as páginas ou clicam no mesmo link repetidamente. Ninguém realmente pede 10 milhões de linhas, porque poucos humanos podem olhar de uma só vez. Portanto, trabalhar em pequenas páginas mantém os dados fluindo e solicita interferência. Você também tem a oportunidade de introduzir um cache compartilhado em RAM na camada de serviços, ou mesmo em um banco de dados RAM.

Você pode até achar que precisa encharcar seu banco de dados ou particionar entre SQL e um armazenamento de chave/valor. Você pode fazer as junções na camada do meio, escalar e descarregar as coisas de união e computação intensiva do servidor de banco de dados.

A regra com a escala da Internet é que o banco de dados é o seu hot spot e você precisa fazer tudo o que puder para impedir que alguém converse com ele! Seja que o cache HTTP local em um iPad, em seu proxy ISPS, no cache de saída do IIS ou em um cache redis, todas essas camadas estão ajudando a espalhar a carga, aliviar a carga.

Então, se Carl chegasse a entrevistar comigo e me dissesse que havia pensado em colocar uma camada de Odata antes de suas caixas SQL, estaria interessado em ouvir o raciocínio dele.

Answer 4

WCF Data Services e Odata suportam o JSON, para que você possa minimizar a carga útil alavancando isso. Além disso, com os serviços de dados do WCF, você pode controlar completamente o acesso aos dados. Você não precisa rolar a estrutura da entidade. Você pode personalizar tudo. O benefício é que a estrutura do protocolo é completamente tratada para você usando os serviços de dados e ODATA da WCF. E consumir o serviço do MVC é uma referência de serviço ADD. O WCF Data Services é executado no WCF, para que você tenha a capacidade de fazer outros serviços da Web além da entrega do tipo Odata, por isso é extremamente flexível.

Existem limitações aqui e ali que vêm com a natureza dos Odata, bem como a maneira como os Serviços de Dados da WCF lidam com Odata, mas eles são bastante específicos e, se surgirem em sua arquitetura, existem maneiras de contornar.

Se sua solução estiver isolada para um único aplicativo da Web, a camada de dados incorporada nesse aplicativo funciona bem. Mas se você tiver alguma necessidade de ter outro aplicativo ou processo, atinja a camada de dados ou a lógica de negócios compartilhada, explorando a opção de colocar sua camada de dados em um serviço de dados WCF vale a pena. Por exemplo, você pode escrever um script do PowerShell para chamar um método de serviço da Web em 2 linhas de código. Portanto, se você possui lógica de domínio que deseja executar em seu aplicativo da Web e a partir de uma linha de comando ou tarefa programada, sua camada de serviço de dados WCF poderá lidar com esse cenário para todos sem precisar duplicar a lógica ou o código.

Muitas maneiras de esfolar um gato. Eu usei as duas abordagens em aplicativos de negócios e não diria que um ou outro deveria ser evitado. Ambos funcionam bem e fornecem muito valor sem serem prejudiciais.

Answer 5

Para ser justo, há benefícios para essa abordagem que podem superar as preocupações de desempenho, que são reconhecidamente tremendas. Um aplicativo construído dessa maneira terá ordens de magnitude mais latência e pode custar várias vezes mais em recursos de computação para executar do que uma solução em processo.

Dito isto, em cenários de desenvolvimento em que os recursos humanos são limitados, isso pode funcionar melhor. Ele permite que os contratados sejam rapidamente contratados para escrever novas telas ou novos aplicativos muito rapidamente em qualquer idioma que lhes convém. Os desenvolvedores podem ficar atualizados mais rapidamente do que uma solução proprietária. Não há mais senhas SA nos arquivos de configuração, injeção de uma camada de segurança personalizada, se necessário, registro e auditoria unificados, combinando vários armazenamentos de dados em um recurso consistente. Se você tem uma plataforma heterogênea, não precisa escrever SDKs, eles já foram escritos em muitos idiomas importantes. O Odata funciona muito bem com o MS Excel, que é uma grande vitória em muitas organizações. Dependendo da sua topologia de rede, pode ser mais barato e ainda mais rápido para percorrer a Internet do que usar uma linha arrendada se você estiver em um escritório remoto ou atrás de um firewall (em um site de clientes fazendo uma demonstração, por exemplo) .

Para conjuntos de dados grandes, a sobrecarga da solicitação e da embalagem se torna menos importante. Para cenários de relatórios, por exemplo. Embora eu nunca tenha projetado algo assim, posso ver onde pode ser útil, dependendo da sua cultura corporativa e dos recursos disponíveis, para consumir terminais ODATAs internamente.