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.
Web: www.versant.com Phone:
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 system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.