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
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
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
read() methods in the
Job class - alterations are made to the objects and then later commited to the database.