Почему профессионалы Ruby on Rails НЕ используют строительные леса?

Ответ 1

У меня есть опыт работы с рельсами, и я редко использую строительные леса просто потому, что моя конечная цель далека от простых действий CRUD. Однако нет строгого правила не использовать строительные леса. Некоторые кодеры нахмурились, потому что это фактически строительные леса, буквально. Это не готовый продукт. Леса поддерживают вас, когда вы строите фактический продукт. Поиск изображений Google для "строительных лесов", и вы должны получить эту идею.

Имейте в виду, что scaffold является одним из многих встроенных генераторов в Rails. Генератор Rails - это просто script, который выводит некоторый общий код. Генераторы очень полезны для экономии времени, и вы быстро найдете написание генераторов для своих собственных нужд.

Ответ 2

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

Это сказало, что строительные леса могут быть довольно мощными в своем собственном праве.

Ответ 3

Важно понимать, что использование рельсов создает эшафот и осознает его ограничения. Леса помогают вам быстро запустить что-то и проверить предположение. Но в реальном мире это не заставит вас слишком далеко. Допустим, вы создали модель с подкладками

rails generate scaffold Article title:string body:text

Отлично! Теперь у вас есть прототип. Но теперь скажем, вам нужно добавить еще одно поле "автор".

rails generate migration add_to_article_author author:string
rake db:migrate

теперь в статьях таблицы есть новый столбец, но файлы в /app/views/articles находятся в том же старом состоянии, то есть в форме не будет поля автора и т.д. Если вы снова запустите эшафот

rails generate scaffold Article title:string author:string body:text --skip-migration

На этот раз вы добавили -skip-migrate, потому что это было сделано раньше, и Rails действительно будет жаловаться на повторную миграцию той же таблицы. Теперь scaffold предложит вам перезаписать созданный файл в первый раз. Overwriting также уничтожит любые изменения, внесенные вами в ваш контроллер /app/controllers/article _controller.rb, или просмотрит файлы, такие как /app/views/article/show.html.erb или index.html.erb

Так как любое достойное приложение Rails имеет собственный код (а не код шаблона, созданный эшафотом), программист Rails должен использовать эшафот только для проверки идеи. Используйте эшафот, чтобы дать вашему клиенту что-то поиграть. Но в реальном мире код шаблона каркаса не используется.

Ответ 4

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

Леса Rails 3 на самом деле довольно приличные, но у него все еще не хватает некоторых вещей, как способ обработки вложенных ресурсов, и он не использует более простой respond_with (более respond_to), который поощряет многословие, где это не необходимо или приветствовать).

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

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

Ответ 5

Я не использую строительные леса по двум причинам:

• Rails scaffolding помещает все в html-таблицы - мне это не нравится
• Я предпочитаю использовать rails_admin gem для моих страниц администратора, поэтому нет необходимости в 90% кода эшафота

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

Ответ 6

Люди до сих пор говорили, что опытные программисты-рельсы не используют строительные леса и, по серьезным причинам, в основном. Я выступаю за то, чтобы новички тоже не использовали строительные леса.

Возможно, вы долгое время ходили с помощью строительных лесов, а затем понимаете, что забыли включить логическое поле published для модели Post, поэтому вы создаете миграцию для добавления атрибута в таблицу (вы мне удалось это сделать). Затем вам также нужно решить, как добавить это в форму, которую создавали строительные леса. Тогда для жизни вы не можете понять, почему он не обновляется, когда вы отправляете свою форму, и после долгих раздоров и впустую вы выясните, что вы не разрешили массовое задание по этому атрибуту, например, эшафот для вас на других, Оказывается, вы ничего не знаете о том, как работает Rails.

Если вы изучаете Rails, вы бы поняли гораздо больше о MVC, если вы сами создали M V и C.

Ответ 7

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