А по-моему, это вполне естественно использовать for для итерации по строчкам таблиц реляционных баз данных. Тем более есть отличная аналогия со списками.
Я делаю API в формате JSON, специфика в основном такова, что данные отдаются и редко пишутся. Trailblazer мне никакой пользы не приносит, только проблемы так как приходится ковыряться в этом disposable. Вместо representable использую AMS. Никакой лапши в контроллерах нет. Типичный тест на контроллер выглядит так — проверка кода ответа, проверка что ответ не пустой и проверка что ответ соответствует JSON Schema.
Я хочу сказать, что Trailblazer — это очередная штука которая помогает организовать код тем, что его не в состоянии организовать сам.
Если кому-то trailblazer подходит, очень хорошо. Но в случае, если gui нет, половина его становится не нужна, и обозначенные проблемы начинают иметь больший вес.
Я трогал его более полугода назад. Тогда он мне показался очень сырым, АПИ постоянно менялся. При попытке разобраться с проблемами, приходится продираться через довольно небрежные исходники, написанные в очень специфичном стиле. Я такой код могу понимать только в дебагере, да и то с трудом. Судя по отсутствию других core-контрибьютеров, такие сложности не только у меня.
Вообще, так можно охарактеризовать весь код этого автора (apotonick) — reform, cells. Эти гемы предполагается использовать вместе с trailblazer.
Еще один момент. Мне показалось, что trailblazer больше ориентирован на работу с формами, вьюхами и т.д.,
В итоге, trailblazer, я не использую, но использую reform вместе с ActiveAdmin. Я от этого не в восторге, но хорошей альтернативы нет.
Например, в контроллере используется CreateArticle, у которого есть зависимость persist_article, которая делает что-то тяжелое (например, внешний вызов).
Тестируя контроллер, я хочу тестировать только его зону отвественности и избежать внешнего вызова. Внедрение зависимости здесь может помочь мне внедрить noop имплементацию persist_article.
Сам паттерн AR гораздо проще DM в реализации и поддержки и покуда у вас достаточно простая бизнес логика, соответствующая модели данных, проще и дешевле использовать AR.
Наоборот, цель такого подхода — сократить взаимодействие между нодами в системе, которая на одной ноде работать не может. Актор содержит весь необходимый стейт и в состоянии сам выдать необходимую информацию о себе.
Так нет же никакой разницы, выполнится запрос сразу или чуть позже. Конечно, итерация происходит не на Scala коде, а в базе.
Все-таки, Elixr был создан Хосе Валимом, который известен как автор и контрибьютер известных руби проектов.
Я делаю API в формате JSON, специфика в основном такова, что данные отдаются и редко пишутся. Trailblazer мне никакой пользы не приносит, только проблемы так как приходится ковыряться в этом disposable. Вместо representable использую AMS. Никакой лапши в контроллерах нет. Типичный тест на контроллер выглядит так — проверка кода ответа, проверка что ответ не пустой и проверка что ответ соответствует JSON Schema.
Я хочу сказать, что Trailblazer — это очередная штука которая помогает организовать код тем, что его не в состоянии организовать сам.
Если кому-то trailblazer подходит, очень хорошо. Но в случае, если gui нет, половина его становится не нужна, и обозначенные проблемы начинают иметь больший вес.
Я о том и говорю, что предложенный подход позволяет решать такого рода проблемы.
Я трогал его более полугода назад. Тогда он мне показался очень сырым, АПИ постоянно менялся. При попытке разобраться с проблемами, приходится продираться через довольно небрежные исходники, написанные в очень специфичном стиле. Я такой код могу понимать только в дебагере, да и то с трудом. Судя по отсутствию других core-контрибьютеров, такие сложности не только у меня.
Вообще, так можно охарактеризовать весь код этого автора (apotonick) — reform, cells. Эти гемы предполагается использовать вместе с trailblazer.
Еще один момент. Мне показалось, что trailblazer больше ориентирован на работу с формами, вьюхами и т.д.,
В итоге, trailblazer, я не использую, но использую reform вместе с ActiveAdmin. Я от этого не в восторге, но хорошей альтернативы нет.
Например, в контроллере используется
CreateArticle, у которого есть зависимостьpersist_article, которая делает что-то тяжелое (например, внешний вызов).Тестируя контроллер, я хочу тестировать только его зону отвественности и избежать внешнего вызова. Внедрение зависимости здесь может помочь мне внедрить noop имплементацию
persist_article.Не всегда это возможно, Например, в rails action нельзя передать зависимость явно.
К сожалению, trailblazer хорош только до тех пора, пока не возникает необходимость смотреть в его код.