Db4o Mvc Application Architecture

Question

I am currently testing out Db4o for an asp.net MVC 2 application idea but there are a few things I'm not quite sure on the best way to proceed.

I want my application to use guessable routes rather than Id's for referencing my entities but I also think I need Id's of some sort for update scenarios.

so for example I want

/country/usa instead of /country/1

I may want to change the key name though (not perhaps on a country but on other entities) so am thinking I need an Id to use as the reference to retrieve the object prior to updating it's fields. From other comments it seems like the UUID is a bit long to be using and would prefer to use my own id's anyway for clean separation of concerns.

Looking at both the KandaAlpha project I wasn't too keen on some aspects of the design and prefer something more along the lines of S#arp architecture where they use things like the [domainsignature] and EntityWithTypedId, IEntityDuplicateChecker, IHasAssignedId, BaseObject and IValidatable in their entities to control insert/update behaviour which seems cleaner and more extensible, covers validation and is encapsulated well within the core and base repository classes.

So would a port of S#arp architecture to Db4o make sense or am I still thinking rdbms in an oodb world?

Also is there a best practice for managing indexes (including Unique ones as above) in Db4o? Should they be model metadata based and loaded using DI in a bootstrapper for example or should they be loaded more like Automapper.CreateMap?

Its a bit of a rambling question I know but any thoughts, ideas or suggested reading material is greatly appreciated.

Thanks Mac

Answer 1

This question contains a lot of different aspects. Let's start.

Normally db4o uses the object-identity to distinguish the different objects. So normally you don't use any ids. However in a web application you loose the object-identity between the requests, so there's no way around using ids.

The internal object ids of db4o can be used for that. However this ids may change when you defragment the database. I guess that you want to have permanent ids to enable links etc. So then these ids aren't a option. The Guid's or the db4o-UUIDs can be used as ids. However both quite are long.

I think the best solution is to add a field which represent the ID of the object. Then you index that field and maybe add an unique constraint to it. This enables you also to used different kinds of ids. For example this could enable you the '/country/usa', because you use the ISO-Code as id. For simple numeric auto-ids you could use a clever id-generator.

I don't know the two frameworks (KandaAlpha, S#arp) you mentioned. It sounds that the stuff still makes sense. You implement Interfaces or Attributes which add specific behavior. For example an attribute which tells the system what field is the id of the object. The attribute ensures that this field is indexed, that the system know how to query etc.

In my application the indexed are added through attributes. There's an db4o-IndexedAttribute you can use. Or you could add your own. In general I think both ways, explicitly configuring or doing the same with meta-data are ok.