Product Reviews

db4Objects Provides Object-Oriented Local Storage

If you're willing to make the mental shift to storing objects instead of data, db4Objects may be the right solution for a distributable local database.

In the July issue of Visual Studio Magazine we reviewed VistaDB , a database engine written entirely in .NET managed code that is tuned for distributed applications needing to store data locally. Now Visual Studio Magazine Tools Editor Peter Vogel looks at db4Objects, a free database engine that offers a unique spin on local data storage.

You want something different in client-side storage for distributed applications? How about object oriented storage with Versant Corp.'s db4Objects (db4o)? In a client, you often just retrieve objects from your server, manipulate them (or create new ones), and return objects to the server. Rather than go through some ORM layer to save data at the client, db4o allows you to just save the object. You don't even have to predefine the tables in your database before saving.

With db4o, the cost involved in saving an object is practically nothing. I retrieved 1,000 rows from a relational database, created objects to hold the rows' values, and stored the results in a db4o database. The time required to retrieve and store the objects was almost identical with the time required to just retrieve the rows. Retrieving the objects through db4o was the same as retrieving the original rows from the relational database. For a client-side database this is more than "good enough" performance.

Deploying db4o is easy since the engine is just another DLL referenced by your application. Integration with Visual Studio is also good -- db4o includes the Object Manager utility (available from the Tools menu) that provides the functionality that you would normally get from Server Explorer. And the price is definitely right: db4o is free.


[Click on image for larger view.]
Figure 1.This Object Manager utility included with db4o allows you to query and update your db4o database.

However, db4o requires a very different syntax for working with data than your relational database, so you can't swap client-side code for server-side code. But, as long as your client code remains on the client, that isn't a problem. Also, lot of the functionality that you take for granted in a relational database environment isn't present in db4o (stored procedures, for instance). Nor is querying as flexible as in SQL (or as fast when multiple classes are involved). However, for local storage those features may not be essential.

If you're willing to make the paradigm shift to thinking of your client as working with objects, even as your server works with data, then db4o is worth investigating as a powerful (and cheap) way to provide local storage in a distributed environment.

db4Objects

Versant Corporation
Web:
www.versant.com
Phone: 650-232-2400
Price: Free
Quick Facts: A database engine for storing and retrieving .NET objects
Pros: Simple deployment, unique object-oriented approach
Cons: No support for stored procedures, inflexible querying





About the Author

Peter Vogel is a principal in PH&V Information Services, specializing in ASP.NET development with expertise in SOA, XML, database, and user interface design. His most recent book ("rtfm*") is on writing effective user manuals, and his blog on technical writing can be found at rtfmphvis.blogspot.com.

Reader Comments:

Mon, Sep 13, 2010 Droopy

I used db4o for 1 year and was very happy with it, until I faced problems with objects activation (very slow for a few thousand objects) and activation depth (also very slow when not specified for certain queries).

Wed, Sep 8, 2010 ragnar

For anyone wondering if its worth the learning curve and adjustments to how you think about data, I started using db4o with my .net projects just under a year ago.

I'll never go back!

Fri, Aug 20, 2010 Peter Vogel Canada

Kirk: I think you're right--if you're just saving and retrieving a single collection it's hard to beat the ease of serializing/deserializing in .NET. It's when you want to go beyond that--handling multiple objects and needing to selectively retrieve them (querying)--that you need something more than a flat file. Moving objects in memory into objects on the disk makes a certain kind of sense, doesn't it?

Fri, Aug 20, 2010 Kirk Davis Bangkok, Thailand

I've looked at db4Objects before, and still think I might end up using it sometime. For a specific project recently, where I have a client (WPF desktop client) caching a lot of objects locally, I ended up just using a BinaryFormatter and pssing it a List(Of myObject), and then writing the resulting stream to disk; this is about seven lines of code, and I use the same function to persist a few different lists (some with > 10,000 items), and even retrieving all 10k on start-up it's pretty fast. But for querying against the local store of data, db4objects seems pretty cool!

Tue, Jul 27, 2010 Peter Vogel Canada

I can see your point...but if you implement a repository pattern on anything then you can implement any functionality you want on any data storage mechanism .

Tue, Jul 27, 2010 Mark Hall Houston, TX

Your comments on the cons of DB4O might be a little misleading for those that are not familiar with the product. Although DB4O has a native query and SODA query syntax, it also implements a LINQ provider over their data context which provides all the flexibility you will probably need in query. Plus with properly placed indexes, performance can be greatly increased. You are, however, correct that there are no stored procedures, but if you are designing your code properly that might not be an issue. What I mean is, if you are implementing a repository pattern over your data access to assist in SoC, the logic that would normally be compiled on the SQL Server in the stored proc would be compiled in your .NET code located in the repository. Hope that helps.

Sat, Jul 24, 2010 Peter Vogel Canada

I'm a big fan of Access (that's where I started my consulting business many years ago)--but it's not a .NET solution and you have to deal with converting from a COM set of interfaces to the .NET world. I discussed my issues with MS SQL Compact edition in the review of VistaDB--both VistaDB (while it's still around) and db4o make installation just so much easier. Haven't looked at using the AppFrabric distributed cache yet (might be a Practical ASP.NET column or a feature article in there...)

Sat, Jul 24, 2010 fregate

Back to the future - MS Access as a local storage in client-server applications? What about AppFabrics distributed cache? Plus do not forget about MS SQL Compact edition....

Add Your Comments Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above