A bit of background information: We have an old database application written in Access that lets users monitor their workload, and the code is... 'procedural' might be too kind. The vast majority of code is hard-wired to form events, there's a lot of duplication, and little to no abstraction. If it needs to fetch data from the database, it'll just do it right there and then, even if that means roughly the same bit of code repeated 6 times for 6 similar buttons (and 6 practically identical database requests). It's not pretty.
I want to rebuild the application in VB.NET, but I'm hitting a bit of a design snag when it comes to writing classes to represent database records as objects - I don't have a huge amount of experience in OO programming (written a few small apps, read lots of books and material, regular SE lurker), so this is my first OO database application.
The problem is that a given 'job' for a user has a lot of fields on the database. About 30 or so - ID, Title, Requestor, Request Date, Target Date, Priority, Type, Approval... and so on. First pass: Whack everything into a dirty great Job
class:
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. I'm sure you can see my hesitance at having such an enormous class sitting front-and-center of the application. All those properties seem to be violating encapsulation too - the Private members might as well be Public, but conversely I need to be able to alter fields and later write back to the database.
Second pass: There's a few things in here that could be extracted and situated elsewhere: for example, all those Requestor___
members could sit in a Requestor
class
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
So now I have half a dozen of these. Smaller classes? Feels nice. But it feels like all I've really achieved is essentially database normalisation, which doesn't feel like it should live in the application. And the only real change to the structure is that it takes more steps to get to data items.
And I still have all those properties (which are forcing me to use hungarian notation on my private members, which I'm not a fan of, but VB.NET isn't case-sensitive so I can't use the same names), which still aren't sitting right with me.
Is there a standard pattern or methodology for moving large data items to and from a database? My current best idea is the above with commit()
and read()
methods in the Job
class - alterations are made to the objects and then later commited to the database.