SqlDataSource vs ObjectDataSource

Question

Se uma página web precisa de alguns dados, porque não basta ter uma chamada SQLDataSource um procedimento armazenado? Por que usar um ObjectDataSource para chamar um objeto de negócios que chama o procedimento armazenado? Eu entendo que outras aplicações (permite que aplicativos de desktop Say) construídas sobre o .NET framework pode acessar os objetos de negócios, mas o que se o aplicativo será sempre apenas uma aplicação web?

Para ser mais claro:

Quando se deve usar um SqlDataSource ou ObjectDataSource?

Como se motivar a escolha?

Answer 1

Tendo apenas um SQLDataSource é perfeitamente válido, se é apenas uma demonstração, um protótipo, ou um hack rápido. É rápido, é fácil, ele simplesmente funciona e dá-lhe os resultados que você precisa.

No entanto, quando um aplicativo é projetado e construído para o longo prazo, e antecipa que as coisas (requisitos, desejos de clientes, eventualmente, o esquema de banco de dados) pode mudar, então ele pode fazer muito mais sentido introduzir um bom negócio" "camada -. modelo de seu negócio objetos como objetos, e em seguida, fornecer um mapeamento de banco de dados subjacente a esses objetos de negócios

Como diz o ditado - você pode resolver praticamente qualquer coisa em ciência da computação por mais uma camada de engano (ou abstração) -. Mesmo é aqui

CERTEZA: você pode ir direto ao banco de dados, e com certeza, em primeiro lugar e para a primeira iteração, que é, possivelmente, (ou provavelmente) a maneira mais rápida. Mas, no longo prazo, quando um aplicativo é construído para durar, é geralmente um rápido- e suja forma - o custo de manutenção, o custo de manutenção, o custo eo esforço necessário para mudar de acordo com necessidades seu e seu cliente vai crescer e muito rapidamente, que a solução quick'n'dirty não parece mais tão grande, em termos de esforço.

Assim, para resumir o meu ponto: sim, inicialmente, usando uma fonte de dados SQL direta pode ser mais rápido e mais fácil - para usá-lo quando esse é o ponto importante: para fazer as coisas para uma demonstração rápida, uma prova de conceito- aplicativo estilo. Mas no longo prazo, quando você olha para o tempo de vida de um aplicativo, geralmente é pena investir um pouco mais de esforço para adicionar esta camada de abstração (desenho e codificação), de modo que suas páginas não dependem diretamente os detalhes o debaixo do banco de dados.

Marc

Answer 2

Se você tem uma camada de negócios que você está usando em seus projetos, ObjectDataSource é a escolha natural. Isso se encaixa bem com muitos ORMs, e muitos deles oferecem benefícios adicionais (validação, desfazer, etc). Ele também permite acessar qualquer uma das outras propriedades e métodos que você tem em seus objetos de negócios - não apenas os campos SQL diretas. Isto pode vir a calhar real quando vinculativo - uma vez que permite que você apenas se ligam a propriedades na marcação em vez de ter que escrever um monte de trás código.

Se você está indo por este caminho, misturando SQLDataSource e ObjectDataSource pode levar a confusão na próxima desenvolvedor para pegar seu projeto. Neste caso, eu ficar com ObjectDataSource para a consistência do código.

Se você não tem uma camada de negócio e está apenas acertando SQL diretamente - use o SQLDataSource. Minha preferência pessoal é que todo o seu código SQL deve estar em uma camada de negócios ou de dados, e por causa do que eu quase nunca uso SQLDataSource.

Answer 3

Se você pode aplicar o seu código de camada de negócios no procedimento armazenado o seu melhor para usar SQL fonte de dados

Answer 4

Em teoria objectdatasource é melhor. Mas tudo isso depende de quão bem o modelo de objeto é escrito e documentado. Nós terceirizado de uma empresa que usou um gerador de código personalizado (que eles não nos fornecer) para produzir todas as camadas. Ele acabou por ser um pesadelo para fazer mesmo pequenas mudanças como a adição de uma propriedade ou alterar um tipo de campo. Estou agora a demolição praticamente tudo o que eles fizeram e apenas usando os procedimentos armazenados que eles escreveram.

Meu objetivo a longo prazo é re-escrever o aplicativo a partir do zero usando uma ferramenta e código de modelagem gerador comercial. Se você estiver indo para usar objectdatasource Eu recomendo encontrar uma boa ferramenta de modelagem que inclui um gerador de código flexível.