Entity Framework без БД?

Question

Можно ли использовать Entity Framework 4.3 без привязки модели к реальной БД в серверной части?

Мне нужно построить концептуальную модель базы данных в конструкторе VS, а затем я бы хотел вручную обрабатывать выборки, вставки и обновления различных внутренних баз данных (ужасные устаревшие системы). Мне нужно уметь это делать без EF-стонов о том, что таблицы не отображаются и т. Д. Я понимаю, что это очень странная вещь ...

Причина этого заключается в том, что мы хотели бы перейти от этих устаревших систем к хорошо спроектированной модели данных и среде .NET, но нам все еще необходимо поддерживать функциональность и обратную совместимость со старыми системами в процессе разработки. Затем мы достигнем стадии, когда мы сможем импортировать старые данные (поступающие из примерно 6 разных баз данных) в одну БД, соответствующую модели EF, которую я строю. Теоретически, мы должны иметь возможность перейти от взломанной модели EF к правильной модели EF, соответствующей новой структуре данных.

Это жизнеспособно? Можно ли использовать интерфейс EF с LINQ, фактически не указывая его на базу данных?

Мне удалось запросить устаревшие системы, переопределив сгенерированный DbContext и выставив свойства IQueryable, которые запрашивают старые системы. Моя большая борьба сейчас с фактическим обновлением данных.

Если я могу отслеживать изменения в объектах EF, но не могу сохранить эти изменения. Я должен иметь возможность переопределить метод SaveChanges () в контексте для ручной вставки в различные устаревшие таблицы.

В данный момент я вроде как нахожусь в этом вопросе.

UDPATE 4 сентября 2012 г .: я решил использовать конструктор файлов EDMX для построения модели данных, и я генерирую код с использованием T4. Это позволяет мне вручную писать код отображения в соответствии с моими потребностями. Это также позволяет мне выполнить относительную миграцию устаревших данных позже.

Answer 1

Структура сущностей предназначена для связывания сущностей с хранилищем данных без ручного заполнения. В противном случае вы просто используете классы с linq.

Если вы имеете в виду, что вам не нужно отдельное хранилище данных, такое как sql server, mongo и т. Д., То просто позвольте вашему приложению создать базу данных в виде файла mdb, который включается в ваш файл app_data. Это означает, что вам не нужен сервер данных, так что база данных является частью вашего приложения.

Если, с другой стороны, вам нужен другой способ сохранения в базе данных, вы можете создать свои собственные адаптеры данных, которые будут вести себя так, как вам нравится. Компонент структуры сущности mongo .net является примером этого.

В качестве альтернативы, используя только код, вы можете просто использовать хранимые процедуры для сохранения в базе данных, которые могут быть немного многословными и раздражающими с EF, но могут преодолеть для вас пробел и позволить вам построить хорошую архитектуру с моделью, которую вы хочу, чтобы это было переведено на дерьмо в ваших репозиториях.

Затем, когда новая база данных будет готова, вы можете просто переделать репо, чтобы использовать сохранения, и все готово.

Это, конечно, будет работать только с использованием только кода.

Answer 2

Если бы я был в вашей ситуации, я бы настроил новый сервер БД и связал с ним устаревшие серверы.Затем создайте хранимые процедуры для взаимодействия с EF для INSERT / UPDATE / DELETE.Таким образом, ваш EF-код остается отдельным от устаревшего беспорядка поддержки.По мере вывода из эксплуатации устаревших серверов БД вы можете соответствующим образом обновлять хранимые процедуры.Если у вас больше нет устаревших серверов БД, вы можете либо продолжить использовать sprocs, либо обновить подключение к данным EF, чтобы напрямую использовать схему таблицы.