{"id":695,"date":"2009-10-06T22:28:55","date_gmt":"2009-10-06T21:28:55","guid":{"rendered":"http:\/\/www.gamlor.info\/wordpress\/?p=695"},"modified":"2021-03-11T09:44:57","modified_gmt":"2021-03-11T08:44:57","slug":"db4o-persistent-classes-tips","status":"publish","type":"post","link":"https:\/\/www.gamlor.info\/wordpress\/2009\/10\/db4o-persistent-classes-tips\/","title":{"rendered":"db4o: Persistent Classes Tips"},"content":{"rendered":"

In the last four posts I\u2019ve mostly talked about db4o itself and how to used it. \u00a0All this is actually just the necessary evil for our goal, to persist our data. So here are some very basic tips how to model your persistent classes for db4o (well it applies also to other technologies).<\/p>\n

(All posts of this series: the basics<\/a>, activation<\/a>, object-identity<\/a>, transactions<\/a>, persistent classes<\/a>, single container concurrency<\/a>, Queries in Java, C# 2.0<\/a>, client-server concurrency<\/a>, transparent persistence<\/a>, adhoc query tools<\/a>)<\/p>\n

Don\u2019t Go Berserk With Your Data-Model a.k.a KIS<\/h3>\n

My first advice is extremely general and applies to nearly all engineering areas: Keep It Simple (KIS). Keep your data-model as simple as possible to do the job. Well it\u2019s might fun and challenging to show your great intellect by designing the most awesome data-model ever. However it will almost certainly bite you later when you have to maintain the application.<\/p>\n

Why do I tell this here? Well db4o makes it quite easy to just create a ton of classes and store a complex object graph. But only because its easy to store and retrieve objects\u00a0it doesn\u2019t solve your data-modeling challenges by magic. You still need to evaluate, test and manage your data-model very careful. Otherwise it will end in a mess.<\/p>\n

\"db4o<\/a>

db4o data-model keep it simple<\/p><\/div>\n

Ok, now to more concrete tips.<\/p>\n

Be Careful With Framework Classes<\/h3>\n

Let\u2019s take a look at this innocent looking example. It\u2019s just a very simple class which holds a color. Since\u00a0it is a WPF<\/a>-Application why not using the existing Color-class? Here\u2019s the code:<\/p>\n

using<\/span> System.Windows.Media;\r\n\r\nnamespace<\/span> Db4OSeries\r\n{\r\n    public<\/span> class<\/span> SimpleObject\r\n    {\r\n        public<\/span> Color BackGround { get; set; }\r\n    }\r\n}<\/pre>\n
So you store some colors. It may works fine for a while. However when you take look with the ObjectManager (a tool to view the database) at your database, you notice that there are lots of classes, like Uri, UriParser, Win32.SafeHandles etc. How the hell got those classes into your database? You just stored some SimpleObject-instance with a Color. The answer is within the Color-Class. The Color class may look like it is simple class. However it can hold a reference to a Color-Context, which holds information about how to render colors down to references into the Operation-System.\u00a0<\/p>\n
So what\u2019s the conclusion? Be VERY, VERY careful when you pull in\u00a0framework classes. Normally you don\u2019t have any clue what such a\u00a0class actually stores. That\u2019s information-hiding at work, which is a core-principal of object-oriented programming.<\/p>\n
Furthermore since you don\u2019t have the control of such classes, they might change from version to version. So your application might suddenly breaks.<\/p>\n
\"db4o<\/a>
db4o carful with framework classes<\/p><\/div>\n
You could resolve this problem above by writing your own Color-class. (Which I\u2019ve done in my application). Another approach could be to write a custom object-translator<\/a> which only stores the relevant information and doesn\u2019t store references to system-resources.<\/p>\n
Design Your Data-Model Traversing Friendly<\/h3>\n
To illustrate this point I go back for a moment to Hibernate & Co. With a object-relational-mapper following many relations is normally a very expensive operation. So I often didn\u2019t actually use the relations and preferred queries instead. So when I designed my persisted classes for Hibernate I often didn\u2019t put every possible relation in there.<\/p>\n
Now object-databases are damn good at traversing along the object-references\/-relations. So when you’re designing your persisted classes you should keep in mind how you traverse them later. Really focus on the relations between objects and how they interact.<\/p>\n
\"db4o-navigate\"<\/a><\/p>\n
So my approach is this. I develop first a domain-model<\/a> of the problem I try to solve. As soon as I\u2019m happy with my domain-model I begin to draw the directions I need to navigate through the model.<\/p>\n
An example. I\u2019ve a color, a car and a driver as domain-objects. Do I ever want to know the cars color? Almost certainly. So I draw a navigation-arrow from the car to the color. Do I ever want to know the colors cars? Probably never. So no navigation-arrow back. With the approach I complete the model step by step\u00a0with navigation-arrows. After that I\u2019ve a really good idea what I need to persist and which references I need to store.<\/p>\n
\"domain-model\"<\/a><\/p>\n
Know Your Compiler \/ Language<\/h3>\n
Ok, this is only important in certain scenarios. Again a simple example. I\u2019ve a class which I represents a person.<\/p>\n
    public<\/span> class<\/span> Person\r\n    {\r\n        public<\/span> string<\/span> Name { get; set; }\r\n        public<\/span> int<\/span> Age { get; set; }\r\n    }<\/pre>\n
\u00a0<\/pre>\n
Now you’ve decided to index the Person.Name-property. Now you have to know two things. First is that db4o works with the actual fields of the class. Therefore you\u00a0declare the indexes at the field-level.\u00a0(There’s an attribute\/annotation for that).\u00a0But how the hell do you know what fields this class has? Here you really need to know some details of your compiler \/ language. In this case it the field for the .Name-property is \u2018<Name>k__BackingField\u2019. Other .NET-languages might show an other behavior.<\/p>\n
\"db4o<\/a>
db4o compiler, language, platform<\/p><\/div>\n
Why the hell is this so ugly? As said db4o runs for nearly every Java and .NET version. So the core of db4o is build for the least common features. On top of this are some platform-specific additions like LINQ for .NET. However sometimes some stuff isn\u2019t yet pretty for your platform. Like this auto-property example. So when you hit such a case you might need to know a little more about your language, compiler etc.<\/p>\n
To solve the problem above I use a small utility:<\/p>\n
    public<\/span> class<\/span> Person\r\n    {\r\n        [Indexed]\r\n        public<\/span> string<\/span> Name { get; set; }\r\n        public<\/span> int<\/span> Age { get; set; }\r\n    }<\/pre>\n
And then use a extension-method which takes a type. The extension-method adds the indexes according to the attributes:<\/p>\n
var cfg = Db4oEmbedded.NewConfiguration();\r\ncfg.Common.IndexClass(typeof<\/span>(Person));\r\nvar db = Db4oEmbedded.OpenFile(cfg, \"database.db4o\"<\/span>);<\/pre>\n
The source-code for the utility is at the end of this post.<\/p>\n
Read\/Try\/Ask<\/h2>\n
This is it for today =). Anyway there are lots of tips and advices out there. In the db4o documentation are some advices how to store some types like Blobs, Collections etc<\/a>. On this site are some patterns for persistence<\/a>. However those patterns are mostly for very specific problem which I haven\u2019t encountered yet.<\/p>\n
Next Time<\/h3>\n
Concurrency, oh no, concurrency. =( Next time I give a brief introduction about concurrent operation on a db4o database.<\/p>\n
Index-Utility: DBSchemaUtility.cs<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
In the last four posts I\u2019ve mostly talked about db4o itself and how to used it. \u00a0All this is actually just the necessary evil for our goal, to persist our… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_links_to":"","_links_to_target":""},"categories":[150],"tags":[21,100,295],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/posts\/695"}],"collection":[{"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/comments?post=695"}],"version-history":[{"count":19,"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/posts\/695\/revisions"}],"predecessor-version":[{"id":3833,"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/posts\/695\/revisions\/3833"}],"wp:attachment":[{"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/media?parent=695"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/categories?post=695"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gamlor.info\/wordpress\/wp-json\/wp\/v2\/tags?post=695"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}