Почему для мультидоменности в rails рекоммендуют отдельный класс, а не лямбду?

Question

[Антон Иванов]

Всем привет.

В поисках решений обработки одним приложением запросов на нескольких доменах, я нахожу статьи типа вот этой: stackoverflow.com/questions/4207657/rails-routing-...
В этой и во всех других статьях рекоммендуют использовать класс для определения того, для какого из доменов предназначен данный блок маршрутов.

У меня в роутинге нормально живет (и работает) такая конструкция:

users_site  = ->(request) { 'users.site' == request.host }
api_site  = ->(request) { 'api.site' == request.host }
docs_site  = ->(request) { 'docs.site' == request.host }

constraints users_site do
...
end

constraints api_site do
...
end

constraints docs_site do
...
end

В чем минус такого решения кроме того, что для каждого нового домена надо будет писать отдельную лямбду?
Спасибо.

Answer 1

[Jeiwan]

Никакой разницы. В класс выносят, если слишком много логики в условии. У вас одна только строчка, поэтому достаточно лямбды. Это просто вопрос читаемости кода.
Но я бы вообще никогда не выносил в класс, так как придется каждый раз искать этот класс, лезть в него и разбираться в нем. Лучше, когда всё в одном месте.
Ну и этот ответ на SO морально устарел: сейчас ложить что-то в lib очень плохо. Но где тогда хранить эти классы, я не знаю — обычно это решается в рамках конкретного проекта, каждый делает, как ему удобно.
В дополнение, статья о том, как разбивать routes.rb на несколько модулей: blog.arkency.com/2015/02/how-to-split-routes-dot-r...

Comments

[Антон Иванов]

Спасибо. А где тогда держать вспомогательные классы для приложения, если не в lib?

[Jeiwan]

Антон Иванов: смотря какие. Для моделей есть concerns, для контроллеров обычно создают папку с названием контроллера и в ней создают классы (но вообще, контроллеры не должны быть толстыми, поэтому для них эта проблема не очень актуальна). Что-то лучше вынести в гем. Для путей вот в той статье есть решение. Ну и, конечно, нужно делать сервисы (подробнее здесь — blog.codeclimate.com/blog/2012/10/17/7-ways-to-dec... ).
Обычно всё, что не вписывается в модель-контроллер, кидают в lib, из-за чего эта папка разрастается, превращается в свалку и что-то там найти становится трудно (да и разобраться в найденном тоже не легко, т. к. часто это какие-то обрывки логики).

[Антон Иванов]

Jeiwan: Спасибо, почитаю. В основном интересовало, куда класть классы для реализации API внешних сервисов. Сейчас они в lib "живут"

[Jeiwan]

Антон Иванов: я делал отдельные гемы и подключал к проекту, методы из гема использовал в контроллерах. Если для API уже есть готовый гем, то можно сделать сервисы (Service Object из статьи) с более высоким уровнем абстракции и также вызывать их из контроллеров/моделей.

[Антон Иванов]

Jeiwan: Спасибо

[Jeiwan]

Антон Иванов: Рад помочь.