Лучшая практика для структурирования 'большого' приложения для направляющих

Самая большая проблема, которую я вижу при разделении на несколько приложений, заключается в том, что вы теряете гибкость. Что произойдет, если в будущем ранее административная задача (например, загрузка файла типа) станет «пользовательской задачей»? Вы должны будете перемещать код из одного приложения в другое.

Я бы держал все в одном приложении - и использовал роли для фильтрации того, что каждый пользователь может видеть и делать. Это может быть немного сложнее в начале, но это окупается в ближайшем будущем.

Посмотрите на структуры авторизации, такие как Declarative_authorization или cancan .

Я вижу проблему, с которой вы сталкиваетесь, пытаясь создать приложение, которое будет иметь различные субдомены, чтобы плагин account_manager мог решить вашу проблему.

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

Хотя, если вы думаете о том, чтобы они были в одной базе данных, это довольно просто в рельсах, использующих Install_connection.

Я думаю, что вы можете разделить приложение на три-четыре разных приложения, где набор кластеров будет обрабатывать каждый запрос приложения, поэтому скорость будет хорошей. Кроме того, вы можете объединить подобные функции в одном приложении, чтобы обеспечить простоту их обслуживания.

http://www.railslodge.com/plugins/1113-subdomain-fu

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

Обратной стороной является то, что у вас на самом деле нет изоляция, поскольку все ваши приложения привязаны к одной базе данных. В конечном итоге вы столкнетесь с проблемами масштабирования своей базы данных, но, начав просто с одной базы данных, вы начнете. Одна из стратегий масштабирования позже будет заключаться в добавлении подчиненной базы данных, которую используют клиентский сайт и приложения основного сайта, в то время как приложения администратора используют главную базу данных. Это вместе с ТОННОЙ кэширования уведет вас довольно далеко.

Нет ничего плохого в том, чтобы несколько приложений рельсов обращались к одному БД, однако вам понадобится способ совместного использования общего кода в ваших приложениях. По большей части ваши модели. Я делал это раньше, вставляя все свои модели в плагин, который я разделяю как подмодуль в git или как внешний в svn. Наличие отдельных приложений сделает каждое приложение меньше и более легким в обслуживании.

Однако где вы храните свои миграции? Где вы тестируете свои модели? Я бы выбрал приложение суперадмина. Кроме того, вы вносите изменения в модель или схему, и теперь вам нужно проверить 2-4 приложения и убедиться, что они по-прежнему работают!

Лучшая изоляция, отдельные базы данных и взаимодействие между приложениями через веб-API (SOA) и вам не о чем беспокоиться. SOA Я думаю, это способ пойти после определенного момента, но SOA может быть преждевременным, когда вы только начинаете.

В любом случае, наличие отдельных приложений настраивает вас для SOA, но вы этого не сделаете.

Я бы связал все это в одном приложении, потому что вы не будете дублировать классы (модели, плагины и т. Д.) Во всех приложениях. Также: запуск 4 приложений означает, что у вас будет 4 процесса, все потребляющие память из-за 4 отдельных стека Rails, которые они загрузили.

Компиляция его в одно приложение устраняет эту проблему. Что касается вопроса между сайтом продаж и сайтом пользователей, имеющим разные корни, который может быть решен , как упоминалось ранее , с помощью subdomain_fu . Позвольте мне расширить пример кода из имеющегося у меня приложения:

map.with_options :conditions => {:subdomain => 'logs'} do |admin|
  admin.resources :channels do |channel|
    channel.resources :logs
  end
  map.root :channels
  map.connect ':id', :controller => "channels", :action => "show"
end

Как мы видим здесь, : conditions для метода with_options устанавливает : subdomain в be logs , что означает, что все, что входит в logs.mysite.