POO et DataTables pour Rank Amateurs

Question

Je suis un amateur total qui écrit une petite application pour suivre les modifications apportées aux dossiers. J'imagine que je garderai des informations sur les répertoires à regarder dans un datatiable lié à un gridview, lorsque l'utilisateur cliquera sur un bouton, le programme créera FileSystemWatchers pour garder un œil sur les répertoires et ils enverront leurs messages d'événement à un autre datatable. lié à un autre gridview. Où devrais-je déclarer, initier et manipuler les données dans le vaste monde de la programmation orientée objet? La forme principale, dans main, dans une classe, ou devrais-je "abandonner" et utiliser Visual Studio pour créer automatiquement un DataSet et y coller deux tables?

Answer 1

Bien des chevaux pour les cours. Pour une petite application utilitaire, il serait probablement préférable d’utiliser le VS "Visual / RAD". style de programmation. Par exemple, faites glisser des tableaux, etc., sur le formulaire, comme le montrent la plupart des tutoriels.

Strictement parlant, et pour une application plus grande, une méthode plus correcte consisterait à créer un assemblage séparé (.dll) qui gère l’accès aux données et à appeler les classes de cet assemblage à partir du formulaire principal. Ce concept utilise plusieurs termes, mais vous souhaitez effectivement séparer vos préoccupations. En d'autres termes, laissez l'interface utilisateur gérer les interactions d'interface utilisateur, disposer d'un ensemble / projet / élément distinct qui gère l'interactivité de la base de données, et d'un autre ensemble / projet / élément distinct qui gère la logique métier, etc.

Ces dernières phrases peuvent signifier différentes choses pour différentes personnes, et il n’existe pas de méthode 100% correcte pour faire les choses.

Quelques articles pouvant vous aider:

texte du lien
texte du lien < br> texte du lien

Answer 2

Je suis d'accord avec KiwiBastard: l'utilisation des outils VS pour générer un ensemble de données typé vous procure un avantage considérable.

Cela ne fait que générer des classes. Vous devez toujours gérer une instance du DataSet. Pour une application très simple, où je n'ai pas factorisé l'interface utilisateur et la logique métier dans différentes classes, je le ferais dans le formulaire. Pour une application de toute complexité, cela fait partie de la classe de logique métier.

Ce qui vous épargnera probablement pas mal d'ennuis: la liaison de données est bonne, ADO est bonne, mais certains types de code ADO (notamment les gestionnaires d'événements sur le DataTable) ne fonctionnent pas bien avec la liaison de données. Si vous utilisez BindingSources (et en réalité vous devriez le faire), il est généralement judicieux de suspendre la liaison lorsque vous manipulez les objets du DataSet par programme (comme lors de l'ajout ou de la suppression de lignes). Le coût de la suspension et de la reprise de la liaison est très faible et élimine toute une catégorie de problèmes extrêmement difficiles à diagnostiquer.