This project is read-only.

GUID as an entity ID

Apr 28, 2012 at 3:58 AM


Can a guid be used directly as an entity ID field. I've had a look at the IHasGuid interface but I'm not sure if it is exactly what I'm looking for.

Would it be a reasonable solution to mark the Guid property with the key attribute and have the Guid programmatically generated when an object is created?

The reason I'm looking at doing this is so I can associate objects without specifically identifying their type, ie Attendance types and HR types can both be related to a single Meeting type without the Meeting type having associations and properties for both Attendance and HR types, I only have to look up a unique key to get all Meeting types related to any object.



Apr 28, 2012 at 11:35 AM

I'm pretty sure that you can use a Guid as the entity Id field  -  but that's really a question for Entity Framework, not Naked Objects.  Naked Objects doesn't care about the identity fields.  (The SimpleRepository#FindByKey method takes an int  -  but that's only for prototyping anyway  -  you'de be writing your own repositories/methods for a real application).

That said, I don't think your idea is going to work.  Even though your Guid key will be unique across all classes, how are you going to retrieve the object given its Guid key?  You have to make a call to Instances<T> -  and even if you by-passed Naked Objects and made the call to the DbContext directly, you still have to specify a type.  So you'd have to end up doing a find by key against each of the possible types separately, looking for the match  -  which could end up being very inefficient.

The problem that you are trying to solve  -  'polymorphic associations'  - is one that is very familiar to me and I have explored many different ways of doing it. I assume you've already read the section in the manual:  'How to handle associations that are defined by an interface rather than a class'?  The IHasGuid interface is, to my mind, the best way to implement polymorphic associations -  but, whichever way you do it, you will find that you need to hold two pieces of information  -  the type and the identity of the corresponding object.  You can either munge these two into a single 'compound key' (as described in the examples in the manual), or hold them as two fields.  The Naked Objects  ObjectFinder service provides useful methods to be able to retrieve the objects.