Dlinq is great.
But... I'd love to see support for inherited classes based on joined tables.
my schema uses a table for the base data and a base class with a discriminator field and a joined table to provide the columns of the derived class which provide a single object with properties derived from both the base table and the joined table. This is always a one to one join. I gather this cannot be accomplished by just decorating the derived class with it’s own Table attribute and some sort of ID field for the join Or am I mistaken
Second, I'm not thrilled with the inheritance attributes all being on the base class as this breaks the concept of modularity and independent compilation. 3rd parties will not be able to extend the class with out source code. I’d prefer to have each inheritancemapping attribute on the class that implements the derived class rather than the base class if possible.
I’m really asking for more ORM functionality but I do really appreciate the Linq side too.
Perhaps, this is just a thought, but what if the object hydration was separated from the query I’m sure there must be a dozen valid object hydration scenarios maybe provide the basics and let others implement the others
thanks
Joined Table Inheritance
DoerakNL
"Second, I'm not thrilled with the inheritance attributes all being on the base class as this breaks the concept of modularity and independent compilation. 3rd parties will not be able to extend the class with out source code. I’d prefer to have each inheritancemapping attribute on the class that implements the derived class rather than the base class if possible."
Take a look at C:\Program Files\LINQ Preview\Data\samplemapping.xml and C:\Program Files\LINQ Preview\Samples\C#\SampleQueries\NorthwindMapped.cs ...
There are good reasons to not put the attributes on the subclasses -- the types may not be loaded when you need to retrieve the inheritance mapping information, you need to scan all types everywhere to locate the information, etc. There's a balance to be struck between speed, convenience, and reliability, and this is certainly one of those places where the balance is currently not as convenient as others.
Puttoju
I agree with Phil, ability to subclass base class defined in application framework (your own or third party) is definite requirement. I hoped that external mapping file would resolve dependency between base class and subclass but I get error "Cannot find runtime type for type mapping 'xxx.yyy'." thrown by System.Data.DLinq.MappedRootType.InitDerivedTypes(TypeMapping typeMap).
When it comes to locating subclass types it would make sense to search assemblies in current directory or at least be able to extend TypeMapping element in mapping file to provide relative path to the assembly.
Are there plans to include this functionality in future releases
yuvald
On further review, It's more involved than just implementing the hydration separately it goes to the foundation of building the query.
How do you recognize joins from the class inheritance tree and what do you join on. Also when does a one to one join result in an inherited class and when does it result in a class property. It's all very subjective I suppose.
Still , I would love to be able to build inherited classes based on a joined table.