Object oriented database handling

[DonQuichote]

Mainly to get my own thoughts clear, I wrote an article about handling relational database access the object-oriented way. It is written from the viewpoint of a VB (or VBA) programmer, but should not be very different from approaches in any other object-oriented language.

I hope you find it useful and I also hope to get some useful reactions / tips from whoever reads it.

You can read the article at:

http://huizen.dds.nl/~w-p/article/wrtabrec.htm

Best regards

 

[mikewoodhouse]

Well, having had time to read it, I found it interesting. The approach seems to be generally sound; my main suggestion would be to consider improving cohesion by extracting the database functions from the collection ones. Much as in the Engine-Collection-Class pattern described on MSDN, which, with a little trimming, gives a very useful model.


Mike

 

[Polu]

Hello, DonQuichote.

I've spent too much time in Internet today, but this is a very interesting topic. Here are some ideas; hopefully I'll back tomorrow and write more:

I prefer a separated factory generating collections or objects. Factory will generate a collection (method findByCityOfResidence) or a simple object (method findByID), so I disagree with the idea of having collections as factories.

Also, I prefer a separated class to manage cache, rather than having this functionality coupled with factories.

DAO approach seems to be rigth for me to add new records to our table's

Please, tell me more about why is needed/not needed OnDeletion events. I would like to read why is/isn't needed notify to every user-class that the record was deleted as soon as it occurs.

I'm not really happy with this solution but I use to write 'updates' inside the .Add method; if record previously exists is an update, if not is an insert.

I don't like intermediate classes, but I have not found a clever solution

Regards.

Polu.

 

[DonQuichote]

Hello, Polu. Thanks for your comments

I prefer a separated factory generating collections or objects. Factory will generate a collection (method findByCityOfResidence) or a simple object (method findByID), so I disagree with the idea of having collections as factories.

I don't fully understand this. think you mean that you have extracted the object creation into a separate class?

Also, I prefer a separated class to manage cache, rather than having this functionality coupled with factories.

I would like to extract a good deal of functionality from my "lazy collections" into other classes (and I am doing so for some database functions). However, I am running into the problem of not wanting too general classes for specific solutions. I could store the objects is a standard collection, for instance. But then I'd lose a great deal of compiler type checking and cause my application to do a huge lot of casting.
It's a bit like the collections framework in Java. I still wonder why somebody would write a strongly-type language and then force everybody to use only generic types.

DAO approach seems to be right for me to add new records to our table's

I like the idea too, especially because DAO is one of the examples I encountered that does use the collection/member approach. However, it was not clear the first time I used it, that the create method did not add the member to the collection itself. This is a situation where I would have liked a separate factory myself. Hey! I am learning as I type this!

Please, tell me more about why is needed/not needed OnDeletion events. I would like to read why is/isn't needed notify to every user-class that the record was deleted as soon as it occurs.

The truth is that I did not need to delete persistent objects in my work. It is just my idea of keeping both the database representation and the object model consistent. It probably is a not so much of a problem in the real world: If you have a reason to delete the object from the database, your application (if it is consistent) will not have any reason to anything else with it.
One issue I a can imagine is that the application wants an inventory of what's still there.

In visual Basic, not every user class has to respond to events. Only if you write an event routine, you respond to the event.

I'm not really happy with this solution but I use to write 'updates' inside the .Add method; if record previously exists is an update, if not is an insert.

I did not encounter an example where I do not know if the record is present beforehand in my work. I did encounter a "last changes" table. For that table, I have my collection pass an appropriate NullObject, which causes itself to insert, rather than modify an existing record.

I don't like intermediate classes, but I have not found a clever solution

Too bad. I couldn't come up with something better as well ;-)

Best regards

 

[Polu]

Hello again, DonQuichote.

I propose two classes to manage one entity. Let's say we owns a table called "Customer".

There will be one class called "dbCustomer" and a second class called "memCustomer".

"memCustomer" will be a container class, and it will be used to store one row. No much logic will be placed here, only data validation like date formats, account number validations a such things.

"dbCustomer" will provide methods like "findByPrimaryKey", "findByCurrentAddress", etc. This methods will return one object from the class "memCustomer" or one collection containing a number of "memCustomer" objects.

This approach seems to be very closer to J2EE EJB's point of view.

Please, let me know what do you think about that.

Regards.

Polu.

 

[DonQuichote]

At first sight, that looks like my situation: the

dbCustomer

class is the collection class or table wrapper that returns

memCustomer

objects. Am I right?

Alas I'm not familiar with J2EE EJB

Best regards