Какой смысл выполнять миграцию EF, когда вы можете использовать SQL непосредственно в базе данных? - PullRequest
Новая
       12

Какой смысл выполнять миграцию EF, когда вы можете использовать SQL непосредственно в базе данных?

0 голосов
/ 02 сентября 2018

Как создать представление (SQL) из Entity Framework в ABP Framework

Запрещено оставлять комментарии из-за репутации. Просто пытаюсь получить больше информации о подключении базы данных к Entity Framework, не переключаясь на стиль разработки кода. Просмотреть ответ выбранного ответа (он сказал ОП, чтобы он делал то же самое, что и в БД, но с EF, а затем добавил дополнительный шаг, где EF "... игнорирует ..." предыдущие инструкции ...

Я хочу создать таблицы и проектировать базу данных непосредственно в SQL, и у библиотеки csharp просто чтение / запись значений таблиц (вроде как функция dapper, когда она не заменяет вашу базу данных, просто работает вместе) сторона этого).

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

Я не хочу делать какие-либо EF migrations (я не хочу / нужно уничтожать / создавать базу данных каждый раз, когда я решаю запустить, продублировать или перенести проект). Любое обратное отслеживание базы данных (резервное копирование / восстановление) должно выполняться с использованием SQL (в моей рабочей среде).

Просто чтобы понять, что именно я пытаюсь выучить: Как кто-то, кто специализируется на администрировании базы данных (построение схемы базы данных, управление данными и мониторинг, а также имеет существующую базу данных с установленными данными), подключается к проекту для получения данных (опять же, специально ссылаясь на функциональность Query Dapper * *1027* ).

Я хочу интегрировать и разрабатывать микросервисы, некоторые могут использовать одно и то же соединение с базой данных или полагаться на другое. Но я просто хочу прочитать данные в чистом строго типизированном объекте класса и, возможно, иметь дело со вставкой / обновлением где-то еще, если потребуется.

Я бы предпочел использовать Dapper вместо EF, но ABP настолько сильно интегрирован с дизайном EF, что это скорее головная боль, чтобы избежать этого, чем просто согласиться с этим.

1 Ответ

0 голосов
/ 03 сентября 2018

Вы должны иметь возможность отображать EF в ABP так же, как и в любом другом проекте, использующем первую конфигурацию DB.

Последовательный подход, который я использую для EF: (DB-First)

  1. Определение сущностей, соответствующих структуре таблицы / представления.
  2. Определите классы конфигурации, расширяющие EntityTypeConfiguration<TEntity> с соответствующими ToTable(), HasKey() и любым HasMany / HasRequired / HasOptional для отношений по мере необходимости.
  3. В DbContext.OnModelCreating: modelBuilder.Configurations.AddFromAssembly(GetType().Assembly); для загрузки всех конфигураций объекта. (при условии, что DbContext находится в той же сборке, что и модели / конфигурации, замените GetType().Assembly, чтобы указать на сборку объекта.
  4. Отключить миграцию. В конструкторе DbContext: Database.SetInitializer<MyDbContext>(null);

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

...