And now on to LINQ to Entities

After way too much work with PLINQO and LINQ to SQL, I discovered that it simply won’t work for my little project.  The problem is that I want to use single table inheritance for some common elements (notes, addresses, etc.); however, I want to be able to access the children of an item as a collection.  For example, assume I have this (not being precise with my code here):

class Relationship
{
public ICollection<RelationshipNote> Notes {get; set; }
}

class RelationshipNote : Note
{
public Relationship Relationship {get; set;}
}

class Note { }

I want to be able to traverse from both ends of the relationship.  In LINQ to SQL, you apparently cannot have this setup.  To be perfectly honest, I’m not clear where in the model it breaks down.  All I know is that it doesn’t work, and it took me 8 different tries and about 10 hours to figure out that the only way you could do this type of setup is if you maintain the RelationshipNote in its own table and use it as a type directly.  And if anyone has an answer about a way to make it work, please do post a comment.  Clearly, I don’t want to have to add a new table whenever I want to associate a note to a new object, so this wasn’t going to cut it.  Maybe I’m crazy, but this doesn’t seem like such a complex or far-out approach to modeling the database or the classes–why it isn’t supported is beyond me.

However, I am using Migrator.Net to create the tables, and so it should be relatively painless to run the migration locally, update the entity data model, update the tests and go.  This is still on the right track, but I didn’t enjoy the detour very much.

And now on to LINQ to Entities.  I’m just now installing VS2008 SP1, so I expect that my next post on this journey will be on whether it does what it supposedly does in the context of my real-world project.