views:

256

answers:

1

I am having trouble with inheritance mapping in Linq to Sql. I am using MSDN as a reference and as a basis it sounds good. However the example it gives is a single table inheritance mapping. However, I am trying to do multiple table inheritance to save on table space. Is this possible? So far I have:

[Table(Name="writing_objs")]
[InheritanceMapping(Code="T",Type=typeof(ObjectTypeA), IsDefault=true)] // Only default because a default is required
[InheritanceMapping(Code="N",Type=typeof(ObjectTypeb))]
public abstract class WritingObject
{
    /* ... */

    [Column(Name="obj_tp", IsDiscriminator=true)]
    [StringLength(1)]
    public string ObjectType { get; set; }
}

I then have the different object types defined like so:

[Table(Name="obj_type_a")]
public class ObjectTypeA: WritingObject
{
    /* Object Type A fields */
}

The issue seems to be that I am defining a table attribute in the 2nd type, as I get the following exception:

The inheritance subtype 'ObjectTypeA' is also declared as a root type.

Is it possible to keep these fields in separate tables with Linq to Sql or am I going to have to consolidate them all into a single table? Is it necessarily bad to have some extra fields in one table as long as there aren't too many (some object types might even be able to share some fields)?

+1  A: 

Linq to SQL does not support multiple-table inheritance using a discriminator, even though that is the best design in many cases (it's the most normalized).

You'll have to implement it using associations instead. If you use a mapping layer that converts it to an inheritance-based domain model, it will be easier to manage at higher layers.

Aaronaught
What do you mean by using a mapping layer that converts it to an inheritance-based domain model? The original intent on using inheritance instead of associations was to simplify ASP.NET MVC model binding, as it seemed to have issues binding multiple objects in one view. I guess I'll just focus on figuring out why that isn't working rather than using inheritance in my entity design.
KallDrexx
@KallDrexx: You can't bind multiple objects to a single view in MVC. That's why you build View Models. In addition to View Models it's also common to have a Domain Model, which is the "real" model of your application/business, intelligent, self-validating, etc., not subject to the restrictions of a relational database. Passing database objects (Linq to SQL classes) directly to your views may work for very small apps, but as you're finding out now, it becomes far more difficult as the app gets larger and more complex.
Aaronaught
Ok I think I understand. I need to split my current Domain Model away from the actual database schema and create domain repositories that convert the database to/from the actual domain models. That makes sense. Thanks!
KallDrexx
Whether you *need* to depends on the size of your project of course; I don't mean to say that "you must always do this", but under the circumstances I think it would be worth the effort. You definitely need at least *one of* a Domain Model or View Model if you need to display the data from more than one Linq to SQL entity in a single view; a Domain Model is probably the better place to start since it can eventually be used for more than just presentation.
Aaronaught
Oh yeah I understand that. I can definitely see other instances where I am going to encounter this issue (for example, recording records to an audit table with commit of actual data), so this is probably the best way for me to do it in the long run, and it's better to start separating the layers now while it's still small.
KallDrexx