db4o oo database
Old forum URL: forums.lhotka.net/forums/t/885.aspx
cultofluna posted on Saturday, August 12, 2006
Hello,
One of the things that is cumbersome about using oo is storing it in a relation database. I found the following site http://www.db4o.com/ a gpl oo database application also available for .net
Does anybody have any experience on using oo databases, db4o or any other oo databases? What are your opinions on whether and when to use oo databases? Isn't an oo database much more faster and easy to use for a heavily oo framework like CSLA?
Curious about your opinions!
Best regards,
xal replied on Saturday, August 12, 2006
Here are some links to threads in the old forum that talk about that:
http://groups.msn.com/cslanet/general.msnw?action=get_message&mview=0&ID_Message=18099
http://groups.msn.com/cslanet/general.msnw?action=get_message&mview=0&ID_Message=22810
I hope these help
Andrés
RockfordLhotka replied on Saturday, August 12, 2006
There's a difference between data-centric entity objects and behavior-based business objects.
ORM tools (in general) are very good at mapping relational data into entity objects. Those entity objects largely mirror the relational data structure, and when they don't the ORM mapping process rapidly becomes unmanagable.
Object databases unfortunately suffer much the same problem. They avoid ORM by just putting your object's fields into a database. But the end result is that your objects must be designed using relational design techniques - meaning that your objects are often even more relational with an ODBMS than with an ORM tool.
Note that I am not passing any value judgement here - just pointing out simple facts. I have experimented with using db4o with and without CSLA. It is very cool, and I like it quite a lot. But the fact is, that you need to carefully design your object model following relational modeling techniques or you rapidly end up in trouble - like having the same customer data fields multiple times in the database... One field can only exist in one class ever (following 3rd normal form) or issues arise.
So my conclusion is this: ODBMS systems like db4o are really nice as replacements for ADO.NET and relational databases. db4o is very fast, very small and very easy to work with. If you use it as a data store behind a behaviorally designed CSLA .NET business layer, you get the best of both worlds - a really nice object data store, and a business layer that encapsulates your validation and authorization logic, and which natively supports data binding.
To do this, simply implement your DataPortal_XYZ methods to use db4o instead of ADO.NET. You still need to copy data between the db4o entity objects and your behavioral business object fields - but that's not hard. And what's important about that, is that you can have multiple customer objects with different responsibilities for different use cases, all using the same underlying customer data entity object that is stored directly into db4o.
DansDreams replied on Monday, August 14, 2006
RockfordLhotka:But the fact is, that you need to carefully design your object model following relational modeling techniques or you rapidly end up in trouble - like having the same customer data fields multiple times in the database... One field can only exist in one class ever (following 3rd normal form) or issues arise.
Can we entertain the idea that such a restriction is actually a good thing in relational DBs, OODBs, AND in the behavioral object layer? We surely all agree that one way or the other we want the representation of the following (logical sorta psuedocode) to exist logically in only one place
public string FullName = FirstName + " " + LastName
I've asked the question before but here I am again - is it completely outrageous to break up the classes such that any particular data OR behavior exists in exactly one class? Which is to say, is the "cleanliness" of such a design from a purity standpoint worth the complexity of the additional classes and relationships?
Copyright (c) Marimer LLC
