C#:O que mais você usa além do DataSet

Question

Estou cada vez mais insatisfeito com o paradigma DataSet/DataTable/DataRow em .Net, principalmente porque muitas vezes são algumas etapas mais complicadas do que o que eu realmente quero fazer.Nos casos em que estou vinculando a controles, os DataSets estão bem.Mas em outros casos, parece haver uma boa sobrecarga mental.

Eu brinquei um pouco com o SqlDataReader, e isso parece ser bom para passeios simples por meio de uma seleção, mas sinto que pode haver outros modelos à espreita no .Net que são úteis para aprender mais.Sinto que toda a ajuda que encontro sobre isso usa DataSet por padrão.Talvez isso e o DataReader sejam realmente as melhores opções.

Não estou procurando uma análise do melhor/pior, apenas curioso para saber quais são minhas opções e quais experiências você teve com elas.Obrigado!

-Eric Sipple

Answer 1

Desde o lançamento do .NET 3.5, uso exclusivamente o LINQ.É realmente muito bom;Não vejo mais razão para usar aquelas velhas muletas.

Por melhor que seja o LINQ, acho que qualquer sistema ORM permitiria que você acabasse com esse lixo.

Answer 2

Afastamo-nos dos conjuntos de dados e construímos nossos próprios objetos ORM vagamente baseados em CSLA.Você pode realizar o mesmo trabalho com um DataSet, LINQ ou ORM, mas reutilizá-lo é (descobrimos) muito mais fácil.'Menos código deixa mais feliz'.

Answer 3

Eu estava farto de DataSets no .Net 1.1, pelo menos eles o otimizaram para que não diminua mais a velocidade exponencial para conjuntos grandes.

Sempre foi um modelo um tanto inchado – não vi muitos aplicativos que usassem a maioria de seus recursos.

SqlDataReader era bom, mas eu costumava envolvê-lo em um IEnumerable<T> onde o T era alguma representação digitada da minha linha de dados.

Linq é um substituto muito melhor na minha opinião.

Answer 4

Eu tenho usado o Objetos de transferência de dados padrão (originalmente do mundo Java, acredito), com um SqDataReader para preencher coleções de DTOs da camada de dados para uso em outras camadas do aplicativo.Os próprios DTOs são classes muito leves e simples compostas de propriedades com get/sets.Eles podem ser facilmente serializados/desserializados e usados ​​para ligação de dados, tornando-os bastante adequados para a maioria das minhas necessidades de desenvolvimento.

Answer 5

Eu sou um grande fã de SubSônico.Um arquivo batch/CMD bem escrito pode gerar um modelo de objeto completo para seu banco de dados em minutos;você pode compilá-lo em sua própria DLL e usá-lo conforme necessário.Modelo maravilhoso, ferramenta maravilhosa.O site faz parecer um acordo ASP.NET, mas de modo geral ele funciona maravilhosamente bem em qualquer lugar se você não estiver tentando usar sua estrutura de UI (com a qual estou moderadamente decepcionado) ou suas ferramentas de geração automática em nível de aplicativo .

Para que conste, aqui está uma versão do comando que uso para trabalhar com ele (para que você não precise lutar muito inicialmente):

sonic.exe generate /server [servername] /db [dbname] /out [outputPathForCSfiles] /generatedNamespace [myNamespace] /useSPs true /removeUnderscores true

Isso acontece sempre...Em seguida, crie a DLL desse diretório - isso faz parte de um projeto NAnt, disparado pelo CruiseControl.NET - e pronto.Estou usando isso em WinForms, ASP.NET e até mesmo em alguns utilitários de linha de comando.Isso gera menos dependências e maior "portabilidade" (entre projetos relacionados, EG).

Observação

O texto acima já tem mais de um ano.Embora ainda tenha muito carinho pelo SubSonic, mudei para o LINQ-to-SQL quando tive o luxo de trabalhar no .NET 3.5.No .NET 2.0, ainda uso o SubSonic.Portanto, meu novo conselho oficial depende da versão da plataforma.No caso do .NET 3+, siga a resposta aceita.No caso do .NET 2.0, escolha o SubSonic.

Answer 6

DataSets são ótimos para demonstrações.

Eu não saberia o que fazer com um se você me fizesse usá-lo.

Eu uso ObservableCollection

Então, novamente, estou no espaço do aplicativo cliente, WPF e Silverlight.Portanto, passar um conjunto de dados ou tabela de dados por meio de um serviço é ...bruto.

DataReaders são rápidos, pois são um fluxo somente direto do conjunto de resultados.

Answer 7

Usei DataSets digitados e não digitados, DataViewManagers, DataViews, DataTables, DataRows, DataRowViews e praticamente qualquer coisa que você possa fazer com a pilha desde que ela foi lançada em vários projetos corporativos.Levei um tempo para me acostumar com o funcionamento da permissão.Eu escrevi componentes personalizados que aproveitam a pilha, já que o ADO.NET não me deu exatamente o que eu realmente precisava.Um desses componentes compara DataSets e atualiza os armazenamentos de back-end.Eu realmente sei como todos esses itens funcionam bem e aqueles que viram o que eu fiz estão muito impressionados por eu ter conseguido ir além e sentir que só foi útil para uso de demonstração.

Eu uso a ligação ADO.NET no Winforms e também uso o código em aplicativos de console.Recentemente, me juntei a outro desenvolvedor para criar um ORM personalizado que usamos em um modelo de dados maluco que recebemos de prestadores de serviço que não se parecia em nada com nossos armazenamentos de dados normais.

Procurei hoje uma substituição para o ADO.NET e não vejo nada que eu deva tentar aprender seriamente para substituir o que uso atualmente.

Answer 8

Eu os uso extensivamente, mas não utilizo nenhum dos recursos "avançados" que a Microsoft estava realmente promovendo quando o framework foi lançado.Basicamente, estou usando-os como listas de hashtables, o que considero perfeitamente útil.

Não vi bons resultados quando as pessoas tentaram criar DataSets de tipos complexos ou tentaram realmente configurar os relacionamentos de chave estrangeira entre tabelas com DataSets.

Claro, sou um dos estranhos que prefere um DataRow a uma instância de objeto de entidade.

Answer 9

Antes do linq, usei o DataReader para preencher a lista dos meus próprios objetos de domínio personalizados, mas depois do linq, tenho usado L2S para preencher entidades L2S ou L2S para preencher objetos de domínio.

Assim que tiver um pouco mais de tempo para investigar, suspeito que os objetos do Entity Framework serão minha nova solução favorita!

Answer 10

Selecionar uma ferramenta ORM moderna, estável e com suporte ativo deve ser provavelmente o maior impulso à produtividade que praticamente qualquer projeto de tamanho e complexidade moderados pode obter.Se você está concluindo que absolutamente precisa escrever seu próprio DAL e ORM, provavelmente está fazendo errado (ou está usando o banco de dados mais obscuro do mundo).

Se você estiver fazendo conjuntos de dados brutos e linhas e tudo o mais, passe o dia experimentando um ORM e ficará surpreso com o quanto mais produtivo você pode ser sem todo o trabalho penoso de mapear colunas para campos ou preencher o tempo todo Objetos de comando SQL e todos os outros saltos que todos nós passamos.

Eu adoro Subsonic, embora para projetos de menor escala junto com demos/protótipos, eu também ache o Linq to Sql muito útil.Eu odeio a EF com paixão.:P

Answer 11

Usei DataSets digitados para vários projetos.Eles modelam bem o banco de dados, impõem restrições no lado do cliente e, em geral, são uma tecnologia sólida de acesso a dados, especialmente com as mudanças no .NET 2.0 com TableAdapters.

DataSets digitados recebem má reputação de pessoas que gostam de usar palavras emotivas como "inchado" para descrevê-los.Admito que gosto mais de usar um bom mapeador O/R do que usar DataSets;simplesmente "parece" melhor usar objetos e coleções em vez de DataTables, DataRows digitados, etc.Mas o que descobri é que se por algum motivo você não puder ou não quiser usar um mapeador O/R, DataSets digitados são uma boa escolha sólida, fáceis de usar e fornecerão 90% do benefícios de um mapeador O/R.

EDITAR:

Alguns aqui sugerem que os DataReaders são a alternativa “rápida”.Mas se você usar o Reflector para observar o interior de um DataAdapter (pelo qual os DataTables são preenchidos), verá que ele usa... um DataReader.Conjuntos de dados digitados poderia ocupam mais memória do que outras opções, mas ainda não vi um aplicativo onde isso faça uma diferença tangível.

Use a melhor ferramenta para o trabalho.Não tome sua decisão com base em palavras emotivas como “nojento” ou “inchado”, que não têm base factual.

Answer 12

Acabei de construir meus objetos de negócios do zero e quase nunca uso o DataTable e especialmente o DataSet, exceto para preencher inicialmente os objetos de negócios.As vantagens de construir o seu próprio são testabilidade, segurança de tipo e intellisense, extensibilidade (tente adicionar a um DataSet) e legibilidade (a menos que você goste de ler coisas como Convert.ToDecimal(dt.Rows[i]["blah"].ToString() )).

Se eu fosse mais inteligente, também usaria uma estrutura ORM e DI de terceiros, mas ainda não senti necessidade deles.Estou fazendo muitos projetos menores ou acréscimos a projetos maiores.

Answer 13

NUNCA uso conjuntos de dados.Eles são objetos grandes e pesados ​​que só podem ser usados ​​(como alguém apontou aqui) para "demoware".Existem muitas alternativas excelentes mostradas aqui.