IQueryable pipline, with inheriting ORM model

Question

I am trying to implement a media library system, and I started out my design from the POCO. I am planning to decouple the actual data access from the object so that, I may persists the same object in XML or SQL.

What I have in the design is:

public abstract class MediaBase {}
public class Image : MediaBase {}
public class Movie : MediaBase {}
public class Document: MediaBase{}
... // more classes inherits from base

As you can see, the Image/Movie is inheriting from the Media Base class. My problem is with the database design, for Image and Movie, they have common properties (in base class) and some uncommon properties. How should I implement this in the database?

I have two options:

1. Use different tables for Image and Movie.
2. Use one single table to hold the common properties, and use a MediaType (int) field in db to distinguish the type.

But problem is, for example, if I want to get all images, the LINQ will be:

from m in Repository.GetMedia
where m is Image
select m;

It will not work, even it does, I doubt if LINQ might actually loads all the data from database before it can select a specific type out. Am I missing something here?

Answer 1

Don't mix LINQ with OR Mapper! With Entity Framework you have more options (Table per Type: http://msdn.microsoft.com/en-us/library/bb738685.aspx)

What you need is to provide different IQueryalable sources. One for your OR Mapper (LinqToEntities) and one to a MemoryArray.

Something like this should work. Pseodocode!

public class Repository
{
    private bool UseEntityFrameWork = Properties.Settings.UseEntityFrameWork;

    IQueryalable<MediaBase> Media 
    {
        get
        {
            if(UseEntityFrameWork) return _myEFContext.MediaBase;
            else return _myMemoryArrayOfMediaBase;
        }
    }
}

It will not work, even it does, I doubt if LINQ might actually loads all the data from database before it can select a specific type out. Am I missing something here?

No! This depends on your OR Mapper. Entity Framework will do that job.

I am planning to decouple the actual data access from the object so that, I may persists the same object in XML or SQL.

The ADO.NET Team promises that persists ignorant objects will be supported in the .NET 4.0 Version of Entity Framework. With the actual Version this would be not possible. Or not directly, but that's another story.