Есть у меня проект, в котором база данных в некотором смысле "модульная" — некоторые таблицы запросто могут отсутствовать в базе. Их наличие зависит от того, купил ли пользователь соответствующие модули или нет.
На данный момент в проекте используется одновременно несколько подходов работы с данными — и прямые SQL-запросы и Linq2Sql. Я работаю над тем чтобы заменить всё это на Entity Framework. И вот эти "модульные" куски DB схемы меня слегка озадачили. Как с ними работать по-человечески? Есть какие-нибудь проверенные временем подходы?
Мне пока на ум приходит три варианта:
1. Генерируем маппинги для Entity Framework с учётом всех возможных таблиц, в рантайме тщательно следим, чтобы не было обращений к несуществующим таблицам — перед обращением к таблицам из каждого "модуля", проверяем, включен ли этот модуль у клиента. Вроде как должно работать, но потенциально могут всплыть баги там, где забыли сделать проверку. Особенно это чревато в тех местах, где обращение идёт не явно, а через референсы у объектов.
2. Генерируем отдельно маппинги для основной структуры БД и отдельно для каждого модуля. Обращаемся к "модульным" данным в явном виде, через загрузку соответствующего контекста. Этот вариант выглядит разумным, когда количество модулей небольшое — для 3..5 модулей должно быть нормально. Для 30..50, боюсь, получится спагетти-код.
3. Хранимые процедуры. В этом варианте прячем все различия за интерфейсом хранимой процедуры. В этом подходе всё вроде как нормально, за исключением того что хотелось бы иметь всю бизнес-логику на стороне C#.
