Un po 'di informazioni di base: abbiamo una vecchia applicazione di database scritta in Access che consente agli utenti di monitorare il loro carico di lavoro, e il codice è ...' procedurale 'potrebbe essere troppo gentile. La stragrande maggioranza del codice è cablata per formare eventi, c'è un lotto di duplicazione e un'astrazione minima o nulla. Se ha bisogno di recuperare i dati dal database, lo farà proprio lì e poi, anche se questo significa all'incirca lo stesso bit di codice ripetuto 6 volte per 6 pulsanti simili (e 6 richieste di database praticamente identiche). Non è carino.
Voglio ricostruire l'applicazione in VB.NET, ma sto colpendo un po 'l'intoppo del design quando si tratta di scrivere classi per rappresentare i record del database come oggetti - Non ho una grande esperienza in OO programmazione (ho scritto poche piccole app, letto molti libri e materiale, normale lurker di SE), quindi questa è la mia prima applicazione di database OO.
Il problema è che un determinato "lavoro" per un utente ha un lotto di campi nel database. Circa 30 circa - ID, Titolo, Richiedente, Data richiesta, Data obiettivo, Priorità, Tipo, Approvazione ... e così via. Primo passaggio: Whack tutto in una grande classe Job sporca:
Public Class Job
Private mID As String
Private mTitle As String
Private mRequestorName As String
Private mRequestorEmail As String
...
Public Property ID() As String
Get
Return mID
End Get
Set(value As String)
Me.mID = value
End Set
End Property
...
End Class
Yikes. Sono sicuro che puoi vedere la mia esitazione nell'avere una classe così enorme seduta davanti e al centro dell'applicazione. Tutte queste proprietà sembrano violare l'incapsulamento anche - i membri privati potrebbero anche essere pubblici, ma al contrario devo essere in grado di modificare i campi e poi scrivere di nuovo nel database.
Secondo passaggio: ci sono alcune cose che potrebbero essere estratte e collocate altrove: ad esempio, tutti quei membri di Requestor___ potrebbero sedere in una classe Requestor
Public Class Job
Private mID As String
Private mTitle As String
Private mRequestor As Requestor
...
End Class
Public Class Requestor
Private mName As String
Private mEmail As String
...
End Class
Quindi ora ne ho una mezza dozzina. Classi più piccole? Si sente bene Ma sembra che tutto ciò che ho realizzato sia essenzialmente la normalizzazione del database, che non sembra debba vivere nell'applicazione. E l'unica vera modifica alla struttura è che richiede più passaggi per accedere agli elementi dei dati.
E ho ancora tutte quelle proprietà (che mi costringono a usare la notazione ungherese sui miei membri privati, di cui non sono un fan, ma VB.NET non è sensibile al maiuscolo / minuscolo, quindi non posso usare il stessi nomi), che non sono ancora a posto con me.
Esiste uno schema o una metodologia standard per lo spostamento di elementi di dati di grandi dimensioni da e verso un database? La mia migliore idea corrente è quella sopra con i metodi commit() e read() nella classe Job - le modifiche vengono apportate agli oggetti e successivamente vengono eseguite sul database.