Reputation: 12413
I'd not planned for this as the requirement has only just emerged but Using Entity Framework we have pairs of tables (I'll call them Twins, A & B) with identical data structures but different names. This of course maps through via EF as pairs of objects of different types.
What I'd like to do is pretend I only have one table/object and have a switch somewhere (in the repository perhaps) that I can throw to get the data from the B group of tables rather than the A group.
I can't figure out whether there is a useful route using the repo, using structuremap and or polymorphism to enable this to work.
Al alternative might be to put the twin 'B' tables in a second database, and with the same name as their 'A' twin, if that would help at all ?
(Up until today I thought I had two different databases with no crossover and just needed to implement a connection string switch - turns out thats not the case as 80% of the tables are shared between the two states and its just the 3 or 4 that are twinned)
Upvotes: 0
Views: 219
Reputation: 12413
I've found that creating two databases, generating the EF objects from the 1st, then in the 2nd dropping the common tables and replacing them with views back to the 1st with the same name works just fine. This then allows me to quite simply pick up the right connection string in the repository (although swapping repo's with structuremap would probably be neater).
Upvotes: 0
Reputation: 6941
I would implement this through a combination of dependency injection and polymorphism.
Rather than operating directly on the entities (let's call them TwinA and TwinB), I would create the following types...
(pardon the name...not much contextual info in the question)
TwinModel (a projected type of the actual entities..hence view model)
Then, you would have...
ITwinRepository
TwinReposotoryImplA
TwinRepositoryImplB
Depending on the need, the correct Repository would be bound at runtime using structure map (through binding configuration). The implementation differences would be to leverage one Entity set over another (TwinA or TwinB).
From a coding standpoint, you're still coding against ITwinRepository and operating on TwinModel, so consumers won't need be affected with future changes, should you decide to implement a TwinC table. :O
Upvotes: 1