Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
This may be better suited to SO, please migrate if necessary –  Kai Sep 23 '13 at 9:58
    
Read object-relational impedance mismatch, and the external links of this article. –  CL. Sep 23 '13 at 12:50
    
In which environment do you want to access your database? In VB.NET or in VBA? Also, have you established a business value of the change? –  Emmad Kareem Sep 23 '13 at 13:17
    
VB.NET. Not sure why business value is relevant to the question being asked? –  Kai Sep 23 '13 at 13:28
2  
In business, effort spent must be associated with some kind of value. A change to a working software should not be carried out unless there is a value for performing this change. Personally, I would not change code in production if it works correctly and performs well without a tangible business value. As others have already suggested, you may want to look at ORM tools and/or EF. –  Emmad Kareem Sep 23 '13 at 18:00

2 Answers 2

up vote 2 down vote accepted

The answer to your question is that you probably, most of the time, don't need to.

Actually, you're building up your model in such a way that it trivially maps the existing, relational database design. This is a bad approach per se, moreover if that relational design is flawed and/or denormalized. Persistence is support, not kernel.

Instead, focus on concrete problems your application is supposed to solve, and build a model explicitly designed to fulfill those requirements . This model will reflect your application's conceptual domain, much more than it does your data model.

My experience with large database records is that, most of the time, only a subset of columns is required to perform certain operations.

share|improve this answer
    
It may be worth to introduce yourself to domain-driven design. –  rucamzu Sep 25 '13 at 23:11
1  
+1. Design the model code in the way that makes most sense, then have a thin mapping layer to the database schema. –  jhewlett Sep 25 '13 at 23:55

If you're taking the time to re-write the code in another language, take the time to clean up the database. While your normalization steps may seem like they haven't accomplished much, I can assure you that steps like this will pay enormous dividends. If you have a poorly designed database schema, you will have to support that poor design in your source code.

If you can't re-design the database, then it's probably still worth designing the persistence layer correctly in your source code and then have a light-weight layer in your code that can interact with the poorly-designed database.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.