OOP e DataTables per amatori di rango

Question

Sono un dilettante totale che scrive una piccola app per tenere traccia delle modifiche alle cartelle. Immagino che terrò le informazioni sulle directory da guardare in un datatable associato a una gridview, quando l'utente fa clic su un pulsante, il programma creerà FileSystemWatchers per tenere d'occhio le directory e invierà i loro messaggi di evento a un altro datatable associato a un altro gridview. In quale parte del vasto mondo di OOP dovrei dichiarare, avviare e manipolare i database? Il modulo principale, all'interno di main, in una classe, o dovrei "rinunciare a" e utilizzare Visual Studio per creare automaticamente un DataSet e inserire due tabelle in esso?

Answer 1

Bene cavalli per corsi. Per una piccola app di utilità probabilmente staresti meglio usando VS " Visual / RAD " stile di programmazione. Ad esempio, trascina e rilascia tabelle ecc. Sul modulo, come mostra la maggior parte dei tutorial.

A rigor di termini, e per un'app più grande, un modo più corretto sarebbe quello di creare un assembly separato (.dll) che gestisca l'accesso ai dati e chiamate le classi all'interno di quell'assembly dal modulo principale. Questo concetto rientra in una serie di termini, ma in realtà vuoi separare le tue preoccupazioni. In altre parole, lascia che l'interfaccia utente gestisca le interazioni dell'interfaccia utente, abbia un assembly / progetto separato / qualunque cosa gestisca l'interattività del database e un altro assembly / progetto separato / qualunque cosa gestisca la logica aziendale ecc.

L'ultima frase può significare cose diverse per persone diverse e non esiste un modo corretto al 100% di fare le cose.

Alcuni articoli che potrebbero aiutare:

testo del link
testo del link < br> testo del link

Answer 2

Sono d'accordo con KiwiBastard: puoi trarre un certo vantaggio dall'uso degli strumenti VS per generare un DataSet tipizzato.

Questo però genera solo classi. Devi ancora gestire un'istanza del DataSet. Per un'app molto semplice, in cui non ho preso in considerazione l'interfaccia utente e la logica aziendale in diverse classi, lo farei nel modulo. Per un'app di qualsiasi complessità, fa parte della classe della logica di business.

Qualcosa che probabilmente ti farà risparmiare un sacco di problemi: l'associazione dei dati è buona, l'ADO è buona, ma alcuni tipi di codice ADO (in particolare i gestori di eventi sulla DataTable) non giocano bene con l'associazione dei dati. Se stai usando BindingSources (e, in realtà, dovresti esserlo), è generalmente una buona idea sospendere l'associazione ogni volta che stai manipolando gli oggetti del DataSet in modo programmatico (come quando aggiungi ed elimini righe). Il costo della sospensione e della ripresa dell'associazione è molto piccolo ed elimina un'intera classe di problemi che sono estremamente difficili da diagnosticare.