If you want to take two different databases and treat them as if they were the same database, insofar as your application is concerned, then you need a layer of abstraction between them that hides the differences.
I think you have a couple of options here. One would be to use two different EF models and then you see repository pattern to abstract the differences between them away. A second option would be to do some sort of conditional mapping.
You have not been very specific about the differences between the databases, so it's difficult to give specific examples of each option, but the general idea for the first is that you write an interface representing the storage, like this:
interface IAnimalRepository
{
IQueryable<Animal> SelectAll();
Animal Insert(Animal newRecord);
// etc.
}
Now you write your service/business layer against this interface, rather than directly against the context.
You can implement the interface for, say the "old" EF mapping, like this:
class AnimalRepository: IAnimalRepository
{
private OldEntities Context { get; set; }
public AnimalRepository(OldEntities context)
{
this.Context = context;
}
IQueryable<Animal> IAnimalRepositorySelectAll()
{
return from oa in Context.OldAnimals
select new Animal // Animal is a POCO
{
Id = oa.Id,
Name = oa.Name
};
}
// etc.
}
The second option is to do a conditional mapping. In this case you would use the new Code First functionality which is currently in CTP for Entity Framework 4, which allows you to specify table and row names at runtime.
Of the two options, I would probably choose the repository pattern option, because I think you'll want to use the repository pattern anyway. It makes unit testing and other concerns much simpler. But either one will work.