From Rockford Lhotka's Expert C# 2008 and VB 2008 Business Objects books
db4o is an object database. No row, no tables, no SQL, no need to make conversion between objects and data, the objects are saved in the database as objects (http://www.db4o.com ) .
I would like to know if someone, here, uses it in a production environment, with the CSLA framework, and what advices he or she could give.
Thanks :)
Cordially
Richard
I am studying it right now ;) .
Do you use both (CSLA and db4o) in a production environment?
On the old forum there was quite a bit of discussion about db40, so you might want to try to find it. Keep in mind that the discussion was a few years ago, but at that time there was a few features still lacking, like a completely robust concurrency model (admitted by the developers).
The bottom line BACK THEN AT LEAST was that it was a fascinating concept but not really quite ready for prime time in an enterprise environment.
I would be really interested if you find out those issues have been resolved.
From what I can tell they have resolved most of those issues and then some. One feature that stands out is transparent activation. It looks like they can instrument our objects so that field data isn't loaded until accessed. If it works as avertised it could eliminate the need to stay away from many data centric designs because of performance and scalablility issues.
As an example that was dicussed at length in another thread an Order object could have a full Customer object reference instead of borrowing fields into the Order using SQL joins undernieth as not all the Cutomer fields would be loaded from the db when you load the Order.
It also supports transactions,online backup, a few different query languages, a "server" mode so it doesn't have to be in-proc, and even a GUI "enterprise manager" now.
Too bad the don't support a royalty free license which pretty much excludes it for my development purposes at this point, otherwise I would spend more time to see if it actually can do some of these things properly.
Justin
Justin:If it works as avertised it could eliminate the need to stay away from many data centric designs because of performance and scalablility issues.
ajj3085:Performance and scalability issues haven't been listed as reasons to stay away from data centric designs.. at least not here.
Hmm, sure didn't sound like Rocky was describing it as poor design but instead impractical because of physical architecture issues, but maybe I misinterpreted this? (from thread http://forums.lhotka.net/forums/3/12361/ShowThread.aspx):
RockfordLhotka: This is where, with real OO applications, people get into trouble. Are you really proposing that, to get one field of data on Order, you are going to load the entire Customer object? I’ve been down that road, early in my exploration of OO. It sounds so sexy. Total reuse. One object with one set of data. One object to rule them all … and in the darkness bind them. (sorry, I’m a hopeless LoTR geek…) But in reality it is bunk. It simply doesn’t work for anything beyond a handful of users, if that. The performance and scalability ramifications are non-trivial, especially in any sort of distributed environment. You can get away with a lot if the database is on the user’s workstation and so, by definition, there’s one user. But as soon as you start trying to load entire Customer objects to get one field of data for dozens or hundreds of users, and that data must travel even from the db to the app server, you are done for. Rocky
This is where, with real OO applications, people get into trouble.
Are you really proposing that, to get one field of data on Order, you are going to load the entire Customer object?
I’ve been down that road, early in my exploration of OO. It sounds so sexy. Total reuse. One object with one set of data. One object to rule them all … and in the darkness bind them. (sorry, I’m a hopeless LoTR geek…)
But in reality it is bunk. It simply doesn’t work for anything beyond a handful of users, if that. The performance and scalability ramifications are non-trivial, especially in any sort of distributed environment.
You can get away with a lot if the database is on the user’s workstation and so, by definition, there’s one user. But as soon as you start trying to load entire Customer objects to get one field of data for dozens or hundreds of users, and that data must travel even from the db to the app server, you are done for.
Rocky
ajj3085:It seems to me that comment is why you wouldn't want to use an OODB vs. a traditional relational db, which is a different (although somewhat related) topic than the 'build business objects based on behavior, not data.' Regardless of your datastore, you'd still want to avoid data centric designs for your business objects.
Exactly wheres does that mention a OO vs relational DB? Now please explain why we should avoid a data centric design and borrow fields from the Customer and put them on a Order if performance a scalability were the only issue? Do you do this at the table level too, replicating customer fields on the order table and keeping them in sync with the master customer table?
Almost every argument against a data centric design is based on performance issues which is understandable and exactly why I still use behaivor based design.To me behavior based design is a compromise in most situations and breaks encapsulation and reuse but must be done to implement a working and performant system today.
A system like db4o with transparent activation could remove many of the performance implications of a data centric design leaving you with choice for the best model given your particular application.
Justin:Exactly wheres does that mention a OO vs relational DB? Now please explain why we should avoid a data centric design and borrow fields from the Customer and put them on a Order if performance a scalability were the only issue? Do you do this at the table level too, replicating customer fields on the order table and keeping them in sync with the master customer table?
Justin:Almost every argument against a data centric design is based on performance issues which is understandable and exactly why I still use behaivor based design.To me behavior based design is a compromise in most situations and breaks encapsulation and reuse but must be done to implement a working and performant system today.
Justin:A system like db4o with transparent activation could remove many of the performance implications of a data centric design leaving you with choice for the best model given your particular application.
ajj3085:http://forums.lhotka.net/forums/permalink/12361/12659/ShowThread.aspx#12659At that point, the discussion changes to using an OODB vs. a relation db. The post you quoted was part of that thread of discussion. Data centric design is perfectly fine at the database level. You do things there you wouldn't do when doing behavior based design on the business layer. The reverse is also true.
In the post I quoted Rocky was replying to this post: http://forums.lhotka.net/forums/permalink/12361/12663/ShowThread.aspx#12663 which was purely a question about OO logical design not about which persistence technology it would be implemented on. Rocky's response characterize this as "sexy" but impractical because of performance and you are somehow interpreting this as an argument against an OODBMS's? It seems to me it is describing limitations of current RDBMS technology backing OO designs, but perhaps Rocky would need to clarify.
ajj3085:That's not the arguments for behavior based design that I've seen here; the arguments are that the behaviors (which are dictated by use cases) are where the maintainablity problems come in, and behavior based design is meant to help with maintainablity issues (as is OOD). The desire for reuse is counter to maintainability. In the thread link above, you will find Rocky explain how we want reuse, but at the same time reuse is bad. Behavior based design doesn't break encapsulation, because the behaviors are what is being encapsulated. There's only one object that gives the behavior you want.
Again in Rocky's response the only argument against the "sexy" design was performance issues, but even he describes it as "Total reuse" which has a direct impact on maintainablity no?
Your still dodging the question how does borrowing fields at a sql level in the Order-Customer example provide better maintainablility or is it only for performance reasons?
I could link many sources that point to data centric designs being a better philosphy just as you could about behaivor centric, but since it seems to be an open debate and I would rather hear your arguments as to why behaivor centric is always a better solution, especially how replicating the same properties across multiple classes improves maintainability.
ajj3085:Again, I don't think behavior based design is an attempt to gain performance.
So now it has nothing to do with performance? Again how can you argue replicating properties leads to less maintence and has nothing to do with performance?
IMO behavioural design is not about performance, and maintainability is not about data integrity.
Behavioural (= single responsibility) objects are simpler, the code is easier to understand (and THEREFORE to modify=maintain). Borrowing fields and duplicating data do not constitute significant maintenance issues; convoluted and/or duplicated procedures do.
Why donate?