Quantos objetos DataTable devo usar no meu aplicativo C #?

Question

Eu sou um programador experiente em um legado (ainda orientada a objetos) ferramenta de desenvolvimento e fazer a mudança para C # /. Net. Eu estou escrevendo um aplicativo de usuário único pequena usando SQL Server CE 3.5. Eu li o DataSet conceitual e doc relacionado e meus trabalhos de código.

Agora eu quero ter certeza que eu estou fazendo isso "direito", obter algum feedback de experientes programadores .Net / SQL Server, do tipo que você não fique com a leitura do doc.

Tenho notado que eu tenho um código como este em alguns lugares:

var myTableDataTable = new MyDataSet.MyTableDataTable();
myTableTableAdapter.Fill(MyTableDataTable);

... // other code

Em um único aplicativo de usuário, você normalmente apenas fazer isso uma vez quando o aplicativo é iniciado, instanciar um objeto DataTable para cada tabela e, em seguida, armazenar um ref para ele assim que você sempre apenas usar esse objeto único que já está preenchido com os dados? Desta forma, você jamais iria apenas lê os dados do db uma vez em vez de potencialmente várias vezes. Ou é a sobrecarga de presente tão pequeno que apenas não importa (mais poderia ser contraproducente com grandes mesas)?

Answer 1

Para CE, é provavelmente um problema não. Se você estivesse empurrando este aplicativo para milhares de usuários e todos eles foram batendo um DB centralizado, você pode querer passar algum tempo na otimização. Em uma instância DB monousuário como CE, a menos que você tem dados que diz que você precisa para otimizar, eu não gastar todo o tempo se preocupando com isso. otimização prematura, etc.

Answer 2

A maneira de decidir varys entre 2 principais poucas coisas 1. Os dados são vai ser acessos constantemente 2. Existe uma grande quantidade de dados

Se você é constanty usando os dados nas tabelas, em seguida, carregá-los na primeira utilização. Se você apenas ocasionalmente usar os dados, preencher a tabela quando você precisar dele e depois descartá-lo.

Por exemplo, se você tem 10 telas gui e só usar myTableDataTable em 1 deles, lê-lo em apenas nessa tela.

Answer 3

A escolha realmente não depende de C # si. Tudo se resume a um equilíbrio entre:

1. Quantas vezes você usar os dados em seu código?
2. Será que os dados já mudança (e que você se importa se isso acontecer)?
3. O que é o parente (tempo) custo de obter os dados novamente, em comparação com tudo o seu código faz?
4. Quanto valor você põe em desempenho , contra esforço desenvolvedor / hora (para esta aplicação particular)?

Como regra geral: para aplicações de produção, onde os dados não muda frequentemente, eu provavelmente iria criar o DataTable uma vez e depois agarrar a referência como você menciona. Gostaria também de considerar colocar os dados em uma coleção digitado / list / dicionário, em vez da classe DataTable genéricos, se nada mais, porque é mais fácil deixar a captura compilador meus erros de digitação.

Para um utilitário simples de executar por si mesmo que "começa, faz sua coisa e termina", é provavelmente não vale a pena o esforço.

Você está perguntando sobre o Windows CE. Nesse particular cuidado, eu provavelmente iria fazer a consulta apenas uma vez e espera para os resultados. Móvel OSs têm restrições extras em baterias e espaço que o software de desktop não tem. Basicamente, um sistema operacional móvel faz bala # 4 muito mais importante.

Sempre que adicionar outra chamada recuperação de SQL, você fazer chamadas para bibliotecas externas com mais frequência, o que significa que você provavelmente está correndo mais, alocando e liberando mais memória mais vezes (o que aumenta a fragmentação) e, possivelmente, fazendo com que o banco de dados para ser re -interprete de memória flash. é mais provável muito melhor para agarrar os dados uma vez que você tem isso, supondo que você pode (veja bala # 2).

Answer 4

É mais fácil descobrir a resposta a esta pergunta quando você pensa sobre conjuntos de dados como sendo uma "sessão" de dados. Você preenche os conjuntos de dados; você trabalha com eles; e, em seguida, você colocar a parte de trás de dados ou descartá-lo quando estiver pronto. Então, você precisa fazer perguntas como esta:

1. Como atual faz os dados precisam ser? Você sempre precisa ter a muito, muito mais recente, ou será que o banco de dados não mudar isso com freqüência?
2. O que você está usando os dados para? Se você está apenas usando-o para relatórios, então você pode facilmente preencher um conjunto de dados, executar o seu relatório, então jogue o conjunto de dados de distância, e da próxima vez apenas fazer um novo. Isso vai dar-lhe os dados mais atuais de qualquer maneira.
3. Apenas a quantidade de dados que estamos falando? Você disse que está trabalhando com um relativamente pequeno conjunto de dados, por isso não há um impacto de memória principal se você carregar tudo na memória e mantenha-o lá para sempre.

Uma vez que você diz que é um aplicativo de usuário único, sem um monte de dados, eu acho que você está seguro de carga tudo no início, usá-lo em seus conjuntos de dados, e em seguida, atualizar numa estreita.

A principal coisa que você precisa se preocupar com neste cenário é: E se as saídas de aplicativos de forma anormal, devido a um acidente, falta de energia, etc.? Será que o usuário perde todo o seu trabalho? Mas como acontece, conjuntos de dados são extremamente fáceis de serialize, assim você pode facilmente implementar uma "economia de vez em quando" procedimento para serializar o conteúdo do conjunto de dados em disco para que o usuário não vai perder um monte de trabalho.