RP
смысл это из приложения выносить
Bounded context, все дела. Devise тоже сделан как rails engine
Так что смело выносите, заодно научитесь с энджинами работать
Size: a a a
2020 October 15
VI
если так будешь все выносить, то будет куча энджинов
в этом то и задумка, чтобы все было в отдельных папках (как в Python/Django), чтобы не в одном месте и искать было легче.
VK
Ну и плюс этот код точно можно переиспользовать
RP
в этом то и задумка, чтобы все было в отдельных папках (как в Python/Django), чтобы не в одном месте и искать было легче.
рельса и джанго отличаются сильно в подходах
какой смысл из рельсы джангу лепить
какой смысл из рельсы джангу лепить
NB
в этом то и задумка, чтобы все было в отдельных папках (как в Python/Django), чтобы не в одном месте и искать было легче.
идея не в том, чтобы это было отделено физически. Идея в том, чтобы это было переносимо, расширяемо и de-coupled (не могу вспомнить как по-русски)
NB
Engines как раз и создавались для того, чтобы различные логические (и контекстные) части стистемы можно было выносить и переиспользовать. Авторизация, биллинг, API, нотификации, бла бла бла
NB
Естественно это не требование, а лишь ваше предпочтение при построении архитектуры приложения и системы в целом
VI
идея не в том, чтобы это было отделено физически. Идея в том, чтобы это было переносимо, расширяемо и de-coupled (не могу вспомнить как по-русски)
понял, спасибо.
Вот так и хотел сделать.
В django / express я просто создавал отдельную папку auth и все что касалось этого там и размещал.
Вот так и хотел сделать.
В django / express я просто создавал отдельную папку auth и все что касалось этого там и размещал.
IN
Естественно это не требование, а лишь ваше предпочтение при построении архитектуры приложения и системы в целом
ну энджайн все таки не просто логику - это отдельное приложение
NB
Так авторизация - это и есть под-приложение
IN
всё-таки гемы в этом плане мне больше нравятся
RP
Engines как раз и создавались для того, чтобы различные логические (и контекстные) части стистемы можно было выносить и переиспользовать. Авторизация, биллинг, API, нотификации, бла бла бла
ага, зачем выносить логику просто в отдельный сервис обжект, давай обернем в энджин
NB
понял, спасибо.
Вот так и хотел сделать.
В django / express я просто создавал отдельную папку auth и все что касалось этого там и размещал.
Вот так и хотел сделать.
В django / express я просто создавал отдельную папку auth и все что касалось этого там и размещал.
Ну в рельсе действительно другой подход, как сказали выше. Но рельсы штука гибкая, можно юзать только MVC, а можно выстраивать более высокие уровни абстракций. Всё зависит от того, что предпочитает разработчик
IN
Так авторизация - это и есть под-приложение
ну да, тут я предпочитаю отдельный сервис
NB
ага, зачем выносить логику просто в отдельный сервис обжект, давай обернем в энджин
эм што? вюьхи тоже в сервис объект?
NB
В либку или ещё во что можно вынести что-то типо BCrypt, а вот модели, классы, вьюхи, контроллеры (если система а-ля devise) - то engine самое то
IN
Ну в рельсе действительно другой подход, как сказали выше. Но рельсы штука гибкая, можно юзать только MVC, а можно выстраивать более высокие уровни абстракций. Всё зависит от того, что предпочитает разработчик
есть сторонники DHH и есть те кто: "Чувак, помолчи....")
NB
есть сторонники DHH и есть те кто: "Чувак, помолчи....")
Это да :)
RP
В либку или ещё во что можно вынести что-то типо BCrypt, а вот модели, классы, вьюхи, контроллеры (если система а-ля devise) - то engine самое то
и что ты получаешь от такого подхода? что у тебя папочка вью потоньше будет?