OOP e tabelas de dados para o grau Amateurs

Question

Eu sou um total amador escrever um pequeno aplicativo para acompanhar a mudanças nas pastas. Eu imagino que eu vou estar mantendo informações sobre os diretórios para assistir em uma tabela de dados vinculado a um gridview, quando o usuário clica em um botão, o programa irá criar FileSystemWatchers para manter um olho sobre os diretórios e eles vão enviar suas mensagens de eventos para outra tabela de dados ligado a outro gridview. Onde no grande vasto mundo da OOP eu deveria estar declarando, iniciando, e manipulando as tabelas de dados? O formulário principal, dentro principal, em uma classe, ou eu deveria "desistir" e usar o Visual Studio para automagicamente criar um DataSet e ficar duas tabelas nele?

Answer 1

cavalos bem para cursos. Para um pequeno aplicativo utilitário que você provavelmente seria melhor fora de usar o estilo VS "RAD Visual /" de programação. Por exemplo, arrastar e soltar tabelas etc para o formulário, como a maioria dos tutoriais mostrar.

A rigor, e para uma aplicação maior, uma maneira mais correta seria fazer um conjunto separado (.dll) que o acesso aos dados alças e você chamar as classes dentro desse conjunto do formulário principal. Este conceito vai sob uma série de condições, mas efetivamente você deseja separar suas preocupações. Em outras palavras, deixar que as interações UI punho UI, ter um separado montagem / projecto / whatever que a interatividade banco de dados de alças, e outro / projecto / whatever que a lógica alças negócio assembly separado etc.

Esse último par de frases pode significar coisas diferentes para pessoas diferentes, e não há nenhuma maneira 100% correta de fazer as coisas.

Alguns artigos que ajuda pode:

texto do link
texto do link < br> link de texto

Answer 2

Eu concordo com KiwiBastard: você começa um pouco de benefício de usar as ferramentas VS para gerar um DataSet digitado

.

Isso só gera classes, no entanto. Você ainda tem que gerenciar uma instância do DataSet. Para uma aplicação muito simples, onde eu não ter consignado UI e lógica de negócios em diferentes classes, eu faria isso no formulário. Para um aplicativo de qualquer complexidade, é parte da classe lógica de negócios.

Algo que provavelmente irá poupar-lhe um monte de problemas: a ligação de dados é bom, ADO é bom, mas certos tipos de código ADO (em especial os manipuladores de eventos no DataTable) não jogam bem com a ligação de dados. Se você estiver usando BindingSources (e, realmente, você deveria ser), é geralmente uma boa idéia de suspender a ligação sempre que você está manipulando objetos do conjunto de dados por meio de programação (como, quando você está adicionando e excluindo linhas). O custo de suspender e retomar a ligação é muito pequena, e elimina toda uma classe de problemas que são extremamente difíceis de diagnosticar.