Pergunta

O serviço de dados ADO.NET é a próxima geração de camada de acesso a dados nos aplicativos. Eu já vi muitos exemplos usando -o diretamente de uma camada de interface do usuário, como Silverlight ou Ajax, para obter dados. Isso é quase como tendo um sistema de duas camadas, com a camada de negócios completamente removida. Dal deve ser acessado pela camada de negócios e não diretamente da interface do usuário?

Foi útil?

Solução

O ADO.NET Data Services é mais uma ferramenta a ser avaliada para mover dados.

.NET RIA Services é outro. Muito melhor eu diria.

Vejo serviços de dados ADO.NET como um serviço de baixo nível a ser usado por alguma estrutura de alto nível. Eu não deixaria minha interface do usuário falar diretamente com isso.

O principal problema que vejo com o ADO.NET Data Services tem mais a ver com segurança do que com qualquer outra coisa.

Para tarefas simples/rápidas, em uma intranet, e se você não estiver muito escolhe com seu design, isso pode ser útil. (IMO) Pode ser bastante útil quando você precisa expor rapidamente dados de um banco de dados existente.

Eu digo à mão, mas não seria minha primeira escolha, pois evito o máximo que posso as soluções "rápidas e sujas". Essas soluções são como fantasmas, sempre voltam para assombrá -lo.

Outras dicas

O serviço de dados ADO.NET é a próxima geração de camada de acesso a dados dentro de aplicativos

Eu não tenho ideia de onde você conseguiu este a partir de! Talvez você esteja confundindo os Serviços de Dados ADO.NET com o ADO.NET Entity Framework?


Não se deve assumir que tudo o que a Microsoft produz é de valor para todos os desenvolvedores. Na minha opinião, o ADO.NET Data Services é uma maneira rápida de criar serviços CRUD, que talvez tenham algumas outras operações definidas na entidade, mas as operações são todos procedimentos armazenados. Se tudo o que você precisa é de um serviço orientado ao banco de dados, pode ser o que você deseja. Certamente, há relativamente pouca razão para fazer qualquer codificação para um serviço como este, exceto no banco de dados.

Mas isso não significa que os serviços de dados do ADO.NET "têm um lugar no design geral" de todos os projetos. É algo que preenche clientes suficientes que a Microsoft achava que vale a pena gastar dinheiro desenvolvendo e mantendo -o.

Por falar nisso, eles também pensaram que o ASP.NET MVC era uma boa ideia ...

:-)

Na minha opinião, outras respostas subestimam a importância dos serviços de dados da ADO.NET. Embora usá -lo diretamente em seu aplicativo traga alguma semelhança com o sistema de duas camadas, outros produtos da Microsoft, como serviços .NET RIA, Windows Asure Storage Services com base nele. Pelo contrário, a frase em uma das respostas "para tarefas simples/rápidas, em uma intranet, e se você não estiver muito escolhe com seu design, pode ser útil" pode ser útil para sites públicos, incluindo sites no ASP. NET MVC.

Dino Esposito descreve a força motriz dos serviços de dados ADO.NET em seu blog

http://weblogs.asp.net/desposs/archive/2008/04/21/the-quot-driving-force-quot-pattern-part--of---n.aspx

"ADO.NET Data Services (também conhecido como Astoria)

Força motriz: a necessidade de construir sistemas da Web ricamente interativos. O que é isso em resumo: novo conjunto de ferramentas para a construção de uma camada intermediária ou, melhor ainda, a camada de serviço no topo de uma camada média em qualquer tipo de aplicativo, incluindo aplicativos da classe corporativa. O que é isso em concreto: fornece URLs para invocar os hiperlinks para reduzir os dados ao cliente. Melhor para cenários em que um cliente precisa de um acesso direto parcialmente filtrado aos dados. Não é ideal para consultar dados do IE, mas ideal para a construção de uma nova geração de controles da Web que respiram ajax. E exatamente isso. "

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top