tags:

views:

94

answers:

1

I am trying to come up with the "best" way to implement SQL Data Services flexible entity model where each class could be stored as an entity, even derrived classes.

Example: Every subclass has different

string Id
string Kind
Dictionary<string, object> Properties

So far, I'm heading in the direction of having both an Entity class (with above) and a base class that has some kind of collection like

Dictionary<string, Entity> data

And have each subclass add to that dictionary and just get/set properties like

data["EntityKind"].Properties["PropertyName"]

However, since each class only has ONE Entity, it seems like I should be using some sort of Stack (intead of Dictionary) where each level of the hierarchy knows exactly where it is. Then it occured to me that class inheritance IS the stack, so I thought maybe I was just missing some huge OO concept that would really simplify all of this. Something like

abstract eachsubclassmusthaveitsown Entity entity
+2  A: 

Each class is an entity, and you want to associate some entity metadata with it?

It sounds like Attributes might be your best shot.

You would define a class EntityAttribute, with members to store the metadata needed to describe an entity. That would then allow you to tag entity classes with [Entity]. If all the fields are mandatory, give the attribute class a single constructor that requires the values to be passed.

Then use reflection to discover the entity classes. Note that you only need to do that discovery process once and then cache it, so the performance of reflection should not be an issue.

Daniel Earwicker
Interesting. Can you expand more on that? Are you saying the only association it would have with Entity is through an attribute, it wouldn't contain or derrive from it? A downside would be I'd have to use reflection to convert it to an entity, which many say is too slow to use on server-side app?
divitiae
Just noticed your question mark on your first statement, yes, each class can be stored as an entity
divitiae
Beware of the suggestion that reflection is "slow" - always ask "slow compared to what?" It may be 10x or 100x slower than a method call, but method calls are insanely fast.
Daniel Earwicker
@Earwicker I see, my only concern would be that this will be at such a low level of my architecture that these reflection calls would be happening very frequently, so it could add up. I'll search SO for opinions on reflection.
divitiae
The information returned is not going to change at all during execution. It's hard coded into the class. So you can (as I said in my update above) gather the information once and keep it cached.
Daniel Earwicker
@Earwicker interesting! ok, but even if I do head in this direction, it doesn't answer the question, which is, if I have a superclass: Person with an Id field that's different from its subclass: Customer, is there a good OOP way to store both differently?
divitiae
I guess I could do a CustomerID property tagged with [Entity("Customer", "Id")], it really doesn't have to be called "Id"! I'm now seeing the elegance of your answer!
divitiae