fonte de dados objeto ou código-behind: o que é melhor?

votos
10

Sei que é um assunto que pode levantar um monte de debate, mas eu gostaria de saber o que as pessoas pensam que os vários prós e contras do uso Datasources objeto são. Estou fazendo um projeto agora com outro programador que é experiência e nível de conforto são todos enraizado no ASP clássico, e eu tenho certeza de que lado vai
a) começar o trabalho feito rapidamente b) fazer o trabalho com um mínimo de barulho

Temos uma camada de repositório agradável com objetos de domínio capaz de auto-validação, de modo que os métodos estão no local para fazer qualquer ligação das ODS, ou código-behind vinculativo.

Eu não gosto do ODS para a maioria das razões óbvias, mas se ele me salvar de ter a mão-de código de paginação / classificação / selecionar / inserir / atualizar / cenários apagar, então ele pode realmente ser tão ruim?

Publicado 19/05/2009 em 14:38
fonte usuário
Em outras línguas...                            


7 respostas

votos
10

fontes de dados objeto são agradáveis ​​para pequenos projetos, mas eles não escala bem como você está incorporando informações da camada de dados na camada de interface do usuário de sua aplicação. Gostaria de sugerir que você só usá-los para muito pequenas aplicações e outras coisas teste scratch-pad. Se você tomar uma decisão de design para usá-los estar preparado para lutar com problemas de escala e de manutenção no futuro.

Respondeu 19/05/2009 em 14:43
fonte usuário

votos
7

O maior benefício de DataSourceControls é que eles abstrair várias preocupações sobre o ciclo de vida .NET, proporcionando suporte para expressões de ligação de dados CRUD completo e bidirecionais, ou seja, <% # Bind ( "FirstName")%> (no entanto 2 vias de ligação de dados o meio chupar então você provavelmente não está perdendo nada). Como um padrão de design, é uma idéia muito boa com uma implementação medíocre (tanto como a própria WebForms).

Se você desativar viewstate e encontrar-se tentando descobrir por que suas postagens não estão a ser tratados, ou você acaba tendo que chamar DataBind () em vários lugares, fontes de dados pode tirar um pouco da dor de cabeça, porque as DataBoundControls são inteligentes o suficiente para saber quando eles precisam de dados e eles só exigi-lo da fonte de dados. Sem DataBind () chama necessário.

DataSources também fornecem uma boa maneira de lidar com classificação, filtragem e paginação. A maioria dos desenvolvedores, quando usar o código-behind, não costumam fazer a paginação e, em vez acabam retornando enormes conjuntos de resultados do banco de dados.

A desvantagem de fontes de dados é que não tem havido muitos bons implementações. E, geralmente, você acaba amarrando sua interface web para sua implementação persistência (ie SqlDataSource, LinqDataSource, etc) ou você acaba usando ObjectDataSource, que suga porque é tão limitado, requer que você nomes de classe de código duro e nomes de métodos em sua ASPX e usa reflexão um pouco ineficiente. Devido a isso, ele não é útil para pessoas que usam injeção de dependência ou classes DAO estáticos. É uma classe muito mal concebida e parece quase como uma reflexão tardia por MS.

Pessoalmente, eu preferiria usar DataSources eo código-behind. Use uma fonte de dados para tirar a dor de cabeça do ciclo de vida / viewstate, e depois fornecê-lo com um "Select" evento / delegado no código-behind. Infelizmente ObjectDataSource só pode usar reflexão, no entanto, você poderia facilmente escrever sua própria implementação. Eu tenho a minha própria, mas não é pública. Contudo, antes de eu o escrevi eu usei isso, o que torna-se de algumas das inadequações do ObjectDataSource:

http://mikeoff.blogspot.com/2006/06/objectdatasource-working-alternative.html

Respondeu 18/11/2009 em 00:12
fonte usuário

votos
3

Quanto mais e mais familiar você se torna com o quadro ADO.NET subjacente utilizada, a cada vez menos que você venha a contar com os controles de fonte de dados que são fornecidos com Visual Studio. Eu usei-os religiosamente nos primeiros projetos .NET em que trabalhei, mas eu rapidamente descobri que eu seria muito melhor fora apenas usando os fundamentos de conexão e recuperação de dados em um banco de dados que eu estava em confiar em .NET para fazer a sua melhor tentativa de fazê-lo para mim.

Eu olhar para eles mais ou menos como rodinhas para começá-lo familiarizado com o ciclo de vida de ligação de dados mais ou menos.

Respondeu 19/05/2009 em 14:47
fonte usuário

votos
0

Objectdatasource como qualquer outro xxxDatasource em WebForms é o coordenador entre a sua camada de negócios em grandes aplicações (ou a camada de acesso a dados com as menores) e os próprios controles.

Sua apenas fornecendo dados e outras funcionalidades para a parte visual do seu aplicativo, a interface do usuário impulsionado por seus pontos de vista em seu armazenamento de dados.

As pessoas devem ver esses controles como solicitações e respostas para coisas UI e parar desvio-los ou descartá-las completamente. Eles não são a DAL, eles não são maus, eles são apenas conexões com suas fontes de dados que os controles sabem como falar com muito eficiente.

Se você tiver, por exemplo, uma grade de dados que variates é fonte com base em uma decisão, então dois ObjectDataSources deve ser configurado e que a decisão deve residir na página, não o ObjectDataSource. Esta é a forma preferida para usá-los e evitar os problemas que as pessoas tentam se referir a outras respostas.

Respondeu 05/12/2017 em 20:58
fonte usuário

votos
0

Eu acho que, em geral, o código por trás é mais útil porque fornece um local central para a personalização de conexões da camada de dados. Contanto que você dividir a ação em diferentes camadas, o código por trás pode ser muito escalável.

datasources objeto personalizado, por outro lado, são muito útil porque permite a ligação intrínseca com o controle GridView. O conjunto de dados fornecido pelo objeto personalizado fonte de dados permite a fácil classificação e paginação. O objeto personalizado também fornece uma localização central para o acesso da camada de dados.

Respondeu 19/05/2009 em 14:51
fonte usuário

votos
0

Na minha opinião ambos têm o seu lugar, suas forças e fraquezas. O tempo poupado codificar os elementos que você menciona, em particular paginação e classificação, são grandes ajuda, mas se você quiser fazer qualquer coisa remotamente interessante com eles, eles rapidamente tornar-se esforçado para lidar com eles.

Eu uso ODS quando os dados serão estritamente usado apenas para exibição. Tapa em uma grade de dados, um ODS, e está feito. Mas se esses dados precisam ser manipulados de qualquer forma, eu ficar longe de todo o construída em pedaços, sem grades, há ODS.

Respondeu 19/05/2009 em 14:49
fonte usuário

votos
0

Pessoalmente, acho que isso depende do projeto. Se é um pequeno aplicativo CRUD com um par de páginas, em seguida, a ligação a uma fonte de dados objeto provavelmente será rápida, fácil, e têm poucas consequências.

Se for uma aplicação em larga escala com necessidades adaptados, então você pode achar que é frustrante tentando fazer uma fonte de dados objeto atender a essas necessidades específicas.

Respondeu 19/05/2009 em 14:45
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more