Using interfaces with Linq-to-Sql for decoupling

Question

I am re-factoring a model class into an interface. The model class is auto-generated with Linq-to-Sql.

class FooRepository 
{
    // ...
    public void Add(IFoo foo) 
    {
        db.Foos.InsertOnSubmit(foo);    
    }
}

The InsertOnSubmit method takes an instance of Foo, not an IFoo. I can cast the instance inline to (Foo) and this works, but is there a cleaner way to do this?

I am already using StructureMap, can I add an attribute to the Add method to resolve the type based on my mappings?

Or can I override any of the model classes methods, or use the partial events to accomplish this?

Answer 1

In order to separate the DLINQ model from the controller I tend not to pass the LINQ model around, but have a different model that is used by the controller, that is passed into my class before calling the DLINQ methods.

This way I can have in my controller just the properties needed by the application, even though there may be many other properties available in the database.

This way, should the database structure change only the DAO class, such as FooRepository, has to change, everything else is protected from the ripple effect.

I don't know if you would want to do something like this but it would be a simpler design than using Interfaces I expect.

Answer 2

Dunno if this will suit, but perhaps using genrics might be an idea?

class FooRepository<T>
where T: class, IFoo, new() 
{
    // ...
    public void Add(T foo) 
    {
        db.Foos.InsertOnSubmit(foo);    
    }
}

And you can do something like this -

Foo bar = new Foo();
FooRepository<Foo> foo = new FooRepository<Foo>();
bar.Add(bar);

Or this...

Bar bar = new Bar(); //Bar implements IFoo
FooRepository<Bar> foo = new FooRepository<Bar>();
bar.Add(bar);

That way, T in FooRepository is actually a Foo (or a Bar), not an IFoo, so no casting is required, but the restriction in the where clause means that it must implement IFoo, which Foo (and Bar) does.