Есть у меня проект, в котором база данных в некотором смысле "модульная" — некоторые таблицы запросто могут отсутствовать в базе. Их наличие зависит от того, купил ли пользователь соответствующие модули или нет.
На данный момент в проекте используется одновременно несколько подходов работы с данными — и прямые SQL-запросы и Linq2Sql. Я работаю над тем чтобы заменить всё это на Entity Framework. И вот эти "модульные" куски DB схемы меня слегка озадачили. Как с ними работать по-человечески? Есть какие-нибудь проверенные временем подходы?
Мне пока на ум приходит три варианта:
1. Генерируем маппинги для Entity Framework с учётом всех возможных таблиц, в рантайме тщательно следим, чтобы не было обращений к несуществующим таблицам — перед обращением к таблицам из каждого "модуля", проверяем, включен ли этот модуль у клиента. Вроде как должно работать, но потенциально могут всплыть баги там, где забыли сделать проверку. Особенно это чревато в тех местах, где обращение идёт не явно, а через референсы у объектов.
2. Генерируем отдельно маппинги для основной структуры БД и отдельно для каждого модуля. Обращаемся к "модульным" данным в явном виде, через загрузку соответствующего контекста. Этот вариант выглядит разумным, когда количество модулей небольшое — для 3..5 модулей должно быть нормально. Для 30..50, боюсь, получится спагетти-код.
3. Хранимые процедуры. В этом варианте прячем все различия за интерфейсом хранимой процедуры. В этом подходе всё вроде как нормально, за исключением того что хотелось бы иметь всю бизнес-логику на стороне C#.
Здравствуйте, Artem Korneev, Вы писали:
AK>2. Генерируем отдельно маппинги для основной структуры БД и отдельно для каждого модуля. Обращаемся к "модульным" данным в явном виде, через загрузку соответствующего контекста. Этот вариант выглядит разумным, когда количество модулей небольшое — для 3..5 модулей должно быть нормально. Для 30..50, боюсь, получится спагетти-код.
Один модуль — одна сборка .Net И не поставлять клиенту сборки которые он не купил.
Здравствуйте, BlackEric, Вы писали:
BE>Один модуль — одна сборка .Net И не поставлять клиенту сборки которые он не купил.
Сборка должна быть одна и та же. Софт облачный, так что физический набор сервисов один и тот же для всех клиентов. Разница будет в схемах баз данных и имеющихся в них таблицах.
AK>Сборка должна быть одна и та же. Софт облачный, так что физический набор сервисов один и тот же для всех клиентов. Разница будет в схемах баз данных и имеющихся в них таблицах.
Если сборка должна быть одна и та же, то в ней можно сделать интерфейс обращения к объектам (если переходим на ORM, то мы уже говорим больше об обращении к объектам а не к таблицам) и метаинтерфейс для инициализации основного интерфейса.Для основного интерфейса сделать две реализации. При инициализации основного интерфейса можно с помощью прямого запроса (реализация метаинтерфейса) проверить наличие таблиц. Если таблицы присутствуют, то основному интерфейсу отдавать рабочую реализацию (с помощью метаинтерфейса). Если таблиц нет, то инициализировать интерфейс заглушкой. Т.е. получаем DI и четко выделенный слой DAL.
Здравствуйте, Artem Korneev, Вы писали:
AK>День добрый, коллеги.
AK>Их наличие зависит от того, купил ли пользователь соответствующие модули или нет.
Вот это уже неправильно. Предположим я клиент, попробовал триалку. Таблицы появились. Решил не покупать, а таблицы все равно есть.
И оставлю как есть, куплю через 6 мес, когда бюджет будет
AK>Я работаю над тем чтобы заменить всё это на Entity Framework.
И зачем?
Здравствуйте, Artem Korneev, Вы писали:
AK>Что посоветует вселенский разум?
Очень сложно советовать, не зная всей вашей специфики, поэтому, предложу вариант исходя из своего понимания вашей схемы работы.
Вы сказали, что у вас облачное решение, но с точки зрения работы с базой у вас не мультитенант, а у каждого клиента своя база. При этом само приложение всегда деплоится целиком, со всем набором модулей. А "купил/не купил" — это просто настройка в runtime (условно говоря табличка в базе администрирования у кого какие features куплены). Так?
Если я всё верно понял, то я бы предложил делать так:
Генерируется всегда полная структура базы, везде используется полный набор классов DTO и маппинга, т.е. в коде у вас нигде нет никакой привязки, к тому, что какого-то модуля может не быть. Ваши разработчики пишут код, так, словно заказчик купил полную систему.
Собственно проверка и "отсечение" происходит на уровне либо операций, которые предоставляет модуль, либо "его" данных.
По поводу последнего пункта немного раскрою. У нас была в чем-то похожая задача: клиент может приобрести часть модулей и в зависимости от того, что он купил, его сотрудники видят тот или иной функционал. Как у нас это было сделано:
Фильтрация того, что доступно шла не на уровне данных, а на уровне функционала. Т.е., условно говоря, модель данных общая, но если ты не купил модуль "Отчеты по складам", то ты не увидишь закладку этого модуля в интерфейсе и не сможешь достучаться до соответствующих этому модулю методов сервиса (если работаешь через API).
Т.к. интерфейс исходно затачивался под такой принцип работы, то с ним особых проблем не было — мы просто размечали контроллеры (у нас был ASP.Net MVC), специальными атрибутами на основе которых работало формирование навигации ("запрещенные" модули не появлялись в меню, а при попытке прямого перехода, переход блокировался). Только в тех местах где требовалось ручное "руление" формированием UI использовались специальные хэлперы для проверки текущего контекста.
Для фильтрации доступа в API использовалась разметка сервисов (у нас использовался WCF) авторизационными атрибутами.
Т.е. у нас как таковые данные не принадлежали какому-то модулю, ограничение шло по доступным действиям.
Если же у вас требуется именно фильтрация данных я бы подумал всё равно о варианте типа того, что выше, с той лишь разницей, что вы подключаете какой-либо AOP фреймворк, который будет перехватывать обращения к полям ваших сущностей, и если доступа нет, возвращать пустые данные
Здравствуйте, rm822, Вы писали:
AK>>Их наличие зависит от того, купил ли пользователь соответствующие модули или нет. R>Вот это уже неправильно. Предположим я клиент, попробовал триалку. Таблицы появились. Решил не покупать, а таблицы все равно есть.
У нас нет триалок. Это b2b сегмент.
AK>>Я работаю над тем чтобы заменить всё это на Entity Framework. R>И зачем?
AK>>>Я работаю над тем чтобы заменить всё это на Entity Framework. R>>И зачем? AK>Не люблю спагетти-код.
Все это выглядит как "мне лень разбираться, поэтому перепишу-ка я этот код"
"у этого кода есть фатальный недостаток, он написан не мной!"
Работал я с модульным проектом подобного типа. "Навеселившись" с ним вынес для себя главное — делать модульным не только базу данных, но и работающую с ней бизнес-логику. Причем максимально независимо разводить модули (и базы и бизнес-логики) друг от друга. В идеале, чтобы они друг о друге ничего не знали, а при необходимости общения, делали это через базовое ядро, которое и будет контролировать разрешение/запрещение на работу модуля для конкретного клиента. Таким образом раз и навсегда снимается вопрос "есть или нет для этого клиента та или иная таблица в БД".
Здравствуйте, rm822, Вы писали:
AK>>Не люблю спагетти-код. R>Все это выглядит как "мне лень разбираться, поэтому перепишу-ка я этот код"
Нет, там реально спагетти-код. Entity Framework сам по себе не превратит это в конфетку, но позволит хотя бы не мешать SQL-код с C# кодом, я смогу убрать прямую генерацию кривых SQL-запросов из кода с бизнес-логикой в data access layer.
