none
Подскажите как получить строку подключения RRS feed

  • Вопрос

  • Разрабатывается приложение на ASP.NET Core 2 с блэк джеком и инжекциями. Общая база данных с таблицами от Identity, где каждый User прикреплён к сущности в которой храниться имя базы данных. То есть, каждому юзверю соответствует своя база данных. (Хранить ли имя базы данных в Claim пользователя???) Приложение построено так, что до аутентификации все таблицы берутся только из общей базы данных. После аутентификации все запросы пользователя должны направляться к базе данных прикреплённой за пользователем. 

    Как в контроллере или падже модели получить contex к базе данных с нужным конекшином? 

    22 апреля 2019 г. 19:21

Ответы

  • Ну сказал жо, дескать - щёкотите шмугл: Мультиарендность

    Ващё, сиё решаемо в рамках SQL Server тримя способами - усё до кучи хде TenantID часть перчиного ключа каждой таблицы и каждый запрос нужно фильтровать через данный столбец. Подходит для маленьких наборов данных ибо какой-то NoNameChinaTenant может запросто залочить всю таблицу и тогда GoldenPartnerTenant упрётся в ожидание. пример. Второй способ - каждый арендатор в своём Schema, печеньки - каждый Schema можно в отдельный FileStorage поставить и не нужен TenantID. Такой способ не рекомендуют, когда таблиц много и надо дополнительные Schema реализовывать. Ну и третий способ, каждому арендатору по своей базе (за дополнительную плату). пример Усё просто, щё не понятно?

    А ваще, ASP.NET Core и EF Core получились хорошими и предельно гибкими. Можно так ухитриться, щё реализовать первую и последную схемы вместе без пыли и гама. Третью тоже можно вместе, если таблиц не много и не надо плодить Schema в базах арендаторов (хотя тоже решаемо).

    23 апреля 2019 г. 21:51

Все ответы

  • Ответ нашелся. Кто столкнётся с подобной проблемой сышите по ключевым словам: Multitenant ASP.NET Core


    23 апреля 2019 г. 13:41
  • А можно поинтересоваться для чего в одном проекте бесконечное кол-во баз дынных? В чем хоть какие-то плюсы такого построения проекта?
    23 апреля 2019 г. 15:06
  • Ну сказал жо, дескать - щёкотите шмугл: Мультиарендность

    Ващё, сиё решаемо в рамках SQL Server тримя способами - усё до кучи хде TenantID часть перчиного ключа каждой таблицы и каждый запрос нужно фильтровать через данный столбец. Подходит для маленьких наборов данных ибо какой-то NoNameChinaTenant может запросто залочить всю таблицу и тогда GoldenPartnerTenant упрётся в ожидание. пример. Второй способ - каждый арендатор в своём Schema, печеньки - каждый Schema можно в отдельный FileStorage поставить и не нужен TenantID. Такой способ не рекомендуют, когда таблиц много и надо дополнительные Schema реализовывать. Ну и третий способ, каждому арендатору по своей базе (за дополнительную плату). пример Усё просто, щё не понятно?

    А ваще, ASP.NET Core и EF Core получились хорошими и предельно гибкими. Можно так ухитриться, щё реализовать первую и последную схемы вместе без пыли и гама. Третью тоже можно вместе, если таблиц не много и не надо плодить Schema в базах арендаторов (хотя тоже решаемо).

    23 апреля 2019 г. 21:51
  • Ясно, спасибо за разъяснения.

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

    24 апреля 2019 г. 6:03