Java – Best practices for accessing data in a database while abstracting access

Best practices for accessing data in a database while abstracting access… here is a solution to the problem.

Best practices for accessing data in a database while abstracting access

I’m trying to learn best practices for the following scenarios.

I have a defined set of data objects that change with updates. Some of these objects contain arrays of other objects.

Using sqlite I set the database to the following pattern: each object is on its table. If an object has a child object, it has an fk to the child table.

Table names and objects are subject to change. So, to make it easier to change these, I need to be able to hide database calls. I also need to be able to validate the data before inserting into the database. This validation also varies from object to object, and each object can have different types of validation.

Currently I’m trying to create a DAO for each object. and provide a DatabaseHelper for each object that uses ContentProviders to access the database. Developers then use DAOs to do their jobs.

It seems to get very ugly and complicated. There seems to be an easier way… Maybe some tricks from ContentProviders.

So, is there a way to better integrate ContentProvider into the DAO pattern? Or is there a better way to achieve this goal?

Any suggestions are greatly appreciated.

Solution

I recently created a data access layer in .NET. I created a BusinessObjectBase class and a BusinessObjectsBase (plural) class. Moving generic functionality into these classes is more challenging than initially thought. Here are some tips.

1) Since .Net is a typed language (as is Java), I need to get type information about the derived class that the base class virtual function runs. To do this, I used the Curiously Recurring Template Pattern (although I hadn’t actually heard of it until I realized its usefulness myself): http://en.wikipedia.org/wiki/Curiously_Recurring_Template_Pattern

Basically, it is a generic class that takes its own type as a generic parameter.

2) I rely heavily on reflection. I don’t know how much Java has to provide in a reflective way, though, or if it’s fast enough to be useful for the data access layer. Since the native reflection method was so slow, I had to use the free FasterFlect library I found online.

3) I use PostSharp (Java has Spring to do the same thing) for change tracking so that it only updates objects when they actually change.

4) Okay, here’s the most important part: keep it simple. Even though I used a weird generic pattern, reflection, and aspect-oriented programming to fully implement what I wanted, the core of my DLL is actually simpler than you might think. I did a lot of research to find the perfect ORM tool, but found it not difficult to end up writing just a few functions to dynamically generate my own SQL statements. This is where reflection comes in handy, as I put properties on classes that represent tables in the database, as well as properties that represent fields in the table. This way, you only need to change the properties when the table or field name changes, and….

5) I created a short application (almost fit a page) to read database tables/fields and dynamically generate code files containing classes for each table.

Okay, so you probably don’t want to create something that complicated, but I thought I’d come up with some ideas based on my own experience, maybe you’ll find one or more of them useful 🙂

(As a side note, I know many people will be wondering why you’re going through all this hassle instead of just using your existing ORM.) I found the existing ORMs too cumbersome to use, and my implementation was lighter and faster than any ORM I studied).

Related Problems and Solutions