Good OOP Design Priciples for Handling Database Data [closed]

Question

I feel like I am asking a pretty basic question, and I think I should be able to find a good answer somewhere on the internet. But I am exhausted from searching and have only turned up a couple of dry bones. To top it all off, I am now frightened that this question is probably too subjective:)

Anyhow, here goes the question. What is considered good practice for accessing, processing, and manipulating data from a relational database in an object oriented program? So far in my programming I have been processing database data in a procedural sort of way. I am currently actively trying to improve my OOP habits and I wasn't sure how to handle this issue.

Here is one of the scenarios I am working with. I have a table with many manufacturing job entries in it. The application I am writing (improving) performs a lot of processing on each job. For example I iterate through each row in the table and do the following:

• Post the due date to Google calendar
• create a folder unique to the job in a given directory
• create a work order for the job
• create a contract brief for the job
• manages traveler documents
• email info to a couple people
• etc, the list goes on

You get the point. A lot of processing gets done on each job. Currently I have what most good programmers would call a fantastic crap pile of spaghetti code. Maybe it isn't quite that bad, but almost. I iterate through each row in the table with a for each loop and sequentially perform each action on each row. I don't like the way things are currently designed, but I don't know what to do better.

I would like if I could have a neat object called "Jobs" which would implement all the properties of a job and provide a method for performing each of the actions. Then I could even make a custom collection to handle my jobs and all the world would be brighter. The whole solution would be more readable, easier to maintain, easier to add actions to perform on each job (which happens frequently), etc.

But my problem is I can't figure out how to make the connection between the fancy objects and the database. Should I use some sort of Object-relational mapping (I read all kinds of mixed opinions about this)? Do I just loop through all the rows and convert them to objects which accumulate in a collection? Or is the best option to keep going about such projects in a procedural sort of way? I would love your answers and input.

I am interested in information on this subject in an abstract way. In other words I wonder how to handle a situation like this in general. Not just specific to the example I gave. But of course specifics are great as well. I do most of my programming in Visual Basic and C# with VS 2010.

Answer 1

Look at the Repository pattern. It's a great way to separate data access from business processing in meaningful ways. Applying this pattern I have a few projects:

• Entities - the objects that store stuff
• DataAccess - the ORM DbContext and ADO.NET wrappers
• Repository - wraps queries to present strongly-typed functions to the rest of the app
• TheRest - the other projects / tiers: Business, GUI, etc

See How to use Entity Framework context with dependency injection? for a good description of each of the project types

Answer 2

But my problem is I can't figure out how to make the connection between the fancy objects and the database. Should I use some sort of Object-relational mapping (I read all kinds of mixed opinions about this)?

Yes.

As for the processing. Use the visitor pattern and let all different code which want to process the data register themselves as visitor. You could also use an inversion of control container to manage that (IHandlerOf<Job> or IHandlerOf<TravelerDocument>).

It gives you are more loosely coupled way of processing the data.