Rails - мультитенантное приложение с фреймворком для настройки - PullRequest
Новая
       10

Rails - мультитенантное приложение с фреймворком для настройки

3 голосов
/ 02 мая 2011

Я организую мультитенантное приложение с одной базой кода / приложением, использующим субдомены для обнаружения арендатора, а затем запускаю SET SCHEMA на postgres, чтобы делать забавные вещи.

Моя проблема в том, что определенные клиенты будуттребуют различных уровней настройки для основной базы кода.Не тонна, но, безусловно, достаточно для того, чтобы я не хотел начинать взламывать основные модели и контроллеры, добавляя кучу операторов if.

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

Я исследовал несколько вариантов, включая использование include / extends (mixins).Проблема в том, что в производстве методы остаются в объектах (понятно).Я пытался обойти этот миксологию, но он работает не совсем так, как я задумал, и он немного более инвазивен, чем хотелось бы, мне также неясно, как соотнести его с моделями (в контроллерах я только что попробовал mixin / unmix через фильтры до / после).

Если у кого-то есть идеи, как лучше всего подойти / решить эту проблему, я был бы очень признателен за ваш отзыв.FWIW это Rails3

Ответы [ 2 ]

0 голосов
/ 15 июня 2011

Подойдет ли настройка hooks + plugins для ваших нужд?то есть: встроить дополнительную функциональность в другую модель; при любых действиях, которые вам нужно изменить, проверьте таблицу перехватов, чтобы узнать, требуются ли пользователю какие-либо дополнительные действия, в таблице перехватов также указаны действия, которые необходимо выполнить, чтобы вы могли легко настроить разные конфигурации для разных пользователей.

Если вы нашли лучший ответ на этот вопрос, пожалуйста, обновите.

0 голосов
/ 02 мая 2011

Если вы говорите о переключении баз данных «на лету» между запросами, то я думаю, что вас ждет мир, по крайней мере, когда речь идет об использовании ActiveRecord.Это сильно испортит систему кэширования, так как она запоминает вещи, основанные на ID, а не ID + Schema, что может привести к перекрестному загрязнению.

Как правило, с точки зрения архитектуры, лучше разбить вашу базу данных внутри ииметь каждую запись соответственно.Например: 

class Site < ActiveRecord::Base
  # Represents a site or installation of the application
end

class User < ActiveRecord::Base
  belongs_to :site
end

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

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

...