Вы можете сделать требование, чтобы каждый модуль содержал классы отображения для каждой новой сущности, которую он использует.Когда вы запустите приложение, вы просто будете использовать отражение, чтобы получить все классы, производные от StructuralTypeConfiguration<> (включая как сущности, так и сложные типы), создать экземпляры этих типов и добавить их в коллекцию Configurations в DbModelBuilder (это можно сделать вOnModelCreating).
Это займет некоторое время, но это произойдет только один раз, когда контекст используется в первый раз.Вы можете запустить это создание во время запуска приложения - приложениям просто нужно некоторое время для запуска и настройки всей инфраструктуры, которую они должны использовать.
Редактировать:
У меня естьссылаться на EntityFramework.dll в каждом модуле, который не подходит в этом случае.
Да.Вы хотите позволить другим разработчикам определять свои собственные объекты, которые будут сохраняться вашим основным приложением.В таком случае они должны использовать вашу постоянную среду выбора, чтобы сообщить вашему приложению, как сохранить свои сущности.
Если вы используете репозитории, каждый модуль должен даже содержать свои собственные репозитории для работы со своими собственными сущностями - универсальный репозиторий не существует.Универсальный репозиторий - это лишний ненужный слой, который только усложняет работу с ORM по вашему выбору.Чтобы было понятно - правильная реализация шаблона репозитория не является общей.Он специфичен и предоставляет функциональные возможности доступа к данным для единого объекта или совокупного корня.
Если вы не хотите, чтобы зависимость EF в модулях, либо вообще не использовали EF, либо определяете свой собственный промежуточный уровень отображения, который будетпреобразование в конкретное отображение в вашем приложении - большая работа с нулевой добавленной стоимостью.
Другой вариант просто не позволяет вашим модулям использовать новые объекты, потому что это больше похоже на ваши текущие ожидания.Если разработчик модуля должен определить новые таблицы базы данных для своих сущностей, он также должен уметь работать с постоянством и определять отображение между таблицами и своими сущностями.
При запуске я должен отражать каждый dll модуля, что означает многотяжелых dll, которые нужно отразить и ... есть ли какая-нибудь другая идея?
Вы когда-нибудь видели приложения, такие как Photoshop, Visual Studio или даже приложения MS Office, при запуске?Как вы думаете, что происходит, когда вы видите заставку?Приложение инициализируется - оно загружает и инициализирует его функции и плагины.Даже серверному приложению может потребоваться несколько минут для полного запуска.Вы создаете модульное приложение (не составное), поэтому вы должны заплатить за это требование.
Если вы не хотите использовать отражение самостоятельно, вы можете использовать MEF для построения модульной инфраструктуры.
Звучит так, что EF не является хорошим решением для корпоративного составного приложения, верно?
Вы не предложили никаких корпоративных требований, которые не должны выполняться EF.Вы просто боретесь со своими ожиданиями, чтобы позволить разработчикам модулей использовать новые сущности, но не позволяете им описать, как эти сущности будут сохраняться - но кто это будет описывать?
Вы не создаете составное приложение.Составное приложение принимает существующие функциональные возможности (компоненты, существующие приложения), которые работают отдельно, и объединяет их в новое приложение.Вы создаете модульное приложение, в котором ваше ядро может содержать другие модули, но эти модули не могут работать без вашей хостинг-инфраструктуры.
Стоит ли переходить на Model First? !!
Modelfirst (и EDMX в целом) действительно не подходит для ваших ожиданий, потому что в случае модели first каждому модулю понадобится собственный файл EDMX и собственный контекст.
Вы также не должны использовать автоматическую генерацию базы данных по коду сначалапотому что любой новый модуль либо сломает ваше приложение, либо EF удалит вашу текущую базу данных.
Последнее редактирование, потому что это не дискуссионный форум:
EF не мой единственный DataProvider!У меня должен быть какой-то другой DP, такой как ...
Я не знаю, почему вы это делаете, но это неправильно.Одно приложение (даже модульное) должно использовать одного поставщика (ORM mapper).Если у вас есть другие поставщики данных из-за какого-то устаревшего кода, пусть будет так, но вы должны установить политику единого поставщика для всего нового кода.В противном случае вы боретесь с вашим чрезмерно архитектурным приложением, а не с EF.В этом случае ваши модули всегда будут использовать только одну зависимость от провайдера.
Могу ли я попросить любую надежную ссылку ?!Зачем мне добавлять один репозиторий на модуль, если только один репозиторий может выполнить все мои требования?что избыточно?
Ссылка - это опыт.Есть сотни вопросов о репозитории и EF.Если вы хотите использовать все преимущества EF, универсальный репозиторий не позволит этого или ему придется предоставлять функции, которые недоступны в реализациях для других поставщиков.Если вы используете репозиторий просто для того, чтобы выставить CRUD для одной сущности, вы просто оборачиваете то, что уже IDbSet предоставляет.Я понимаю, что вы используете репозитории, чтобы скрыть ад своих провайдеров.
На самом деле я пытаюсь определить свой собственный слой отображения, потому что он мне нужен в моей архитектуре приложения. Это не бесполезно для меня.
Вы собираетесь написать несколько пользовательских отображений (возможно, XML) и преобразователь для каждого сопоставления для конкретного поставщика.Я не уверен, какой лучший ответ вы ожидаете - за исключением того, что это не очень хороший путь.
Модель или промежуточный слой картографирования, который будет работать в каждом модуле загрузки и отображать объектыесли поддержка EF (что не может, как я знаю), мне нужно что-то вроде начальной загрузки для каждого провайдера для сопоставления сущностей
Это не пропущенная часть EF.Это просто выходит за рамки EF.Любой промежуточный уровень, определенный EF, все еще будет частью EF и не будет поддерживаться другими инструментами.EF может загружать сущности, когда создает модель, но чтобы загрузить их, вы должны сообщить EF об их существовании и о том, как их сопоставить, - так объяснил мой первоначальный ответ.
Я не собираюсь читать лекциюо моем приложении и его архитектуре, но я думаю, что этого достаточно, чтобы вы знали, что это составное / модульное приложение
Может быть, но у составной части нет таких проблем, потому что каждый компонентСоставное приложение не зависит от остальных и может использовать совершенно другое постоянство.Проблема, с которой вы сталкиваетесь, является внутренней для каждого модульного компонента.
Но я могу изменить модель и XML-файл EDMX во время выполнения, верно?
Попробуйте.Подсказка: нет общедоступного API для работы с этим XML на низкоуровневой основе, и нет общедоступного API для изменения загруженной модели.Можно изменить EDMX перед загрузкой, но обычно это означает написание собственного анализатора и компоновщика xml для SSDL, MSL и CSDL.У вас будет один набор файлов сопоставления, обновленный всеми установленными модулями.Вам также нужно будет выполнить обратную операцию, чтобы удалить модуль и правильно удалить все функции из сопоставления.Любая ошибка может повредить ваше приложение, потому что отображение будет повреждено.Моя первоначальная идея с загруженными конфигурациями для отображения кода займет у вас менее одного дня.Сколько времени потребуется, чтобы построить это?
Если вы хотите пойти по этому пути, полностью удалите EF из своего проекта и начните использовать файлы сопоставления NHibernate и hbm.Разработчик модуля создаст сборку с логикой модуля и новыми сущностями, скрипт для таблиц базы данных и файл hbm для каждой сущности.Установка модуля создаст таблицу, добавит сборку в расположение модуля и добавит файлы hbm в каталог подбора карт.Ваш сеанс NHibernate загрузит все файлы сопоставления из этого каталога.