#c# #entity-framework #entity-framework-4 #structuremap
#c# #entity-framework #entity-framework-4 #structuremap
Вопрос:
Я не планировал этого, поскольку требование только что появилось, но с помощью Entity Framework у нас есть пары таблиц (я буду называть их Twins, A amp; B) с идентичными структурами данных, но разными именами. Это, конечно, отображается через EF в виде пар объектов разных типов.
Что я хотел бы сделать, это притвориться, что у меня есть только одна таблица / объект, и где-то есть переключатель (возможно, в репозитории), который я могу использовать для получения данных из группы таблиц B, а не из группы A.
Я не могу понять, существует ли полезный маршрут с использованием репозитория, используя structuremap и / или полиморфизм, чтобы это работало.
Альтернативой может быть помещение двух таблиц «B» во вторую базу данных с тем же именем, что и у их двойника «A», если это вообще поможет?
(До сегодняшнего дня я думал, что у меня две разные базы данных без пересечения и мне просто нужно реализовать переключатель строки подключения — оказывается, это не так, поскольку 80% таблиц разделяются между двумя состояниями, и это только 3 или 4, которые являются двойными)
Комментарии:
1. Три базы данных и соответствующие строки подключения. В первых двух базах данных есть «двойные» таблицы, а в третьей — «общие» таблицы.
2. Между двумя таблицами и разделяемыми таблицами есть FK, поэтому я думаю, что это сломается.
3. Это определенно приведет к сбою. (Я долго размышлял, поэтому я не использовал это в качестве ответа.)
4. Хотя это идея … это заставило меня задуматься, могу ли я использовать 2nd DB, настроить EF из основного, а во вторичном поменять общие таблицы на представления таблиц в основном? Возможно, нет, но я попробую
5. Что вы подразумеваете под идентичной структурой? У них абсолютно одинаковые определения полей? Тогда для чего нужны две разные таблицы? Если это так, то я предлагаю вам вставить флаг различия внутри одной таблицы. Если у них есть пересекающийся набор полей, вы можете извлечь суперкласс и наследовать его. Или вы можете извлечь интерфейс и работать с базой данных только через репозиторий, который будет реализовывать фабричный метод.
Ответ №1:
Я бы реализовал это с помощью комбинации внедрения зависимостей и полиморфизма.
Вместо того, чтобы работать непосредственно с объектами (давайте назовем их TwinA и TwinB), я бы создал следующие типы…
(простите за название … в вопросе не так много контекстной информации)
TwinModel (a projected type of the actual entities..hence view model)
Тогда у вас было бы…
ITwinRepository
TwinReposotoryImplA
TwinRepositoryImplB
В зависимости от необходимости, правильный репозиторий будет привязан во время выполнения с использованием карты структуры (через конфигурацию привязки). Различия в реализации будут заключаться в использовании одного набора объектов над другим (TwinA или TwinB).
С точки зрения кодирования, вы все еще кодируете для ITwinRepository и работаете с TwinModel, поэтому пользователям не нужно будет вносить изменения в будущем, если вы решите внедрить таблицу TwinC. :O
Комментарии:
1. (там не так много контекстной информации, потому что у таблиц есть имена, такие как Order, Class и Div, которые сами по себе сбивают с толку! Twin — это прекрасно!) Между тем проблема в том, что я не предвидел этого, поэтому я кодировал для репозитория, но не использовал подход TwinModel: нужно переделать ужасно много!
Ответ №2:
Я обнаружил, что создание двух баз данных, генерация объектов EF из 1-й, затем во 2-й удаление общих таблиц и замена их представлениями обратно в 1-ю с тем же именем работает просто отлично. Затем это позволяет мне довольно просто подобрать правильную строку подключения в репозитории (хотя замена репозитория на structuremap, вероятно, была бы более аккуратной).