Код EF первый модульный дизайн

Question

Используя сначала код ef4, вы можете создавать и компилировать классы и dbcontext.Что происходит, когда вы хотите добавить некоторые классы / таблицы и отношения в уже скомпилированную dll набора моделей?

Пока что решения, которые я придумал, используют «частичные» классы, которые будут дополнены позжеon, а второй пишет совершенно новый dbcontext, который каким-то образом включает в себя первый или расширяет его, но это будет означать дополнительное соединение дБ на модуль (для контекста дБ).Есть идеи по этому поводу?Какая лучшая практика?Также мне нужно иметь возможность работать с миграциями.

Более конкретно, возможный сценарий выглядит следующим образом:

A) Вы создаете .dll с некоторым классом dbContextBase и таблицами (классами) внутричто.

B) Вы создаете другие .dll, которые зависят / расширяют dbContextBase по-своему *

C) Вы указываете упомянутые .dll в проекте и расширяете их.

Таким образом, в основном вы можете иметь ядро ​​dbContext, затем добавить к нему модуль меню, а затем добавить к нему модуль блога (но он может быть просмотрен модулем Меню для создания меню последних сообщений в блоге и т. Д.).Вдобавок ко всему, если вам нужна конкретная одноразовая функция для блога, вы можете быстро интегрировать ее, но также сохранить обновляемый модуль блога.

Как я понимаю, лучшим способом для этого является Nugetпакеты с исходным кодом для моделей (и тому подобного) для каждого модуля вместо скомпилированных dll.

Answer 1

Вы можете построить некоторую инфраструктуру в ваших основных сборках, которая будет обнаруживать сущности в ваших модулях и регистрировать их в едином контексте.У каждой сущности должен быть класс, производный от EntityTypeConfiguration<> (или ComplexTypeConfiguration<> для сложных типов), который будет описывать отображение.

Когда у вас есть классы отображения, вы можете использовать некоторый интерфейс модуля, чтобы собрать их все для каждого модуля, или использовать отражение для просмотра сборок и создания экземпляров классов отображения.Эти классы могут быть либо непосредственно использованы DbModelBuilder (либо OnModelCreating, либо напрямую).

Также мне нужно иметь возможность работать с миграциями.

Я не уверен, что миграции готовы к этому, потому что у него есть некоторые предварительные условия:

• Все общие таблицы должны обрабатываться базовыми сборками - его собственный DbMigration производный класс (или классы для новыхверсии)
• Каждый модуль должен обрабатывать свои собственные таблицы - свой собственный DbMigration производный класс (или классы для новых версий)
• Модули не должны изменять общие таблицы
• Модулине должен изменять или обращаться к таблицам других модулей

Это означает, что у вас есть специальный набор миграции для ядра и один набор миграции для каждого модуля.Каждый набор миграции определен в отдельной сборке - это может быть потенциальной проблемой.Я сам не пробовал, поэтому не знаю, справится ли это с миграциями EF - я особенно нацеливаюсь на сценарии, когда вам действительно нужны модульные системы, где модули могут быть добавлены или удалены со временем, так что вам нужны обе установки (метод Up)и удаление (метод Down).

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

Answer 2

Поскольку не существует ответа, который фокусируется на проблеме, как я ее сформулировал, я публикую ответ с тем, что кажется наилучшим обходным решением на данный момент.

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

Мы используем локальную ленту рассылок для синхронизации нескольких подмодулей.свободно и быстро.Это также приводит к хорошему опыту обновления, поскольку миграции могут быть легко созданы или импортированы / интегрированы при необходимости

Answer 3

А как насчет этого сценария: один DbContext с некоторыми сущностями, на OnModelCreating, ищет дополнительные классы на внешних сборках, которые наследуются от базовых классов на сборке, где живет этот DbContext.Я хочу иметь возможность обновлять уже созданную базу данных в соответствии с этими классами, предполагая, что они не изменяют базовые таблицы, а только добавляют новые.Это возможно?До сих пор, исходя из моего опыта, используя MigrateDatabaseToLatestVersion, он просто игнорирует новые сущности, то есть не генерирует никаких новых таблиц.