Ну, это, безусловно, популярно. Если вы делаете RoR, не боритесь с парадигмой, продолжайте с этим, в этом весь смысл RoR.
Если вы в состоянии определить свою парадигму, то дело в том, что MVC, как правило, просто MV. Контроллер, по мнению некоторых сторонников шаблона, больше предназначен для множественных представлений, что почти всегда не так в данном проекте (хотя в конечном итоге данные могут в конечном итоге рассматриваться по-разному в другом контексте внутри предприятия). , В зависимости от графического интерфейса, отдельный контроллер может помочь в тестируемости кода (если контроллер выступает в качестве тестируемого класса, а компонент GUI просто выполняет тестируемые методы самым минимальным возможным способом).
MVC возникла из толпы SmallTalk, которая совсем недавно попала в морфический паттерн (где объект отображает себя через внутренний класс, который подклассирует соответствующие компоненты GUI). Это не сложный способ сделать HTML-материал наверняка, потому что HTML не может быть эффективно предоставлен дизайнерам.
Лично, если я действительно собираюсь с нуля, я предпочитаю шаблон Presentation (я видел, что он так называется, но сейчас не могу найти ссылку), где представление и привязка данных помещаются в класс представления. Сила шаблона проявляется, если представление всего экрана состоит из различных представлений частей данных. В простых скучных бизнес-приложениях (типа, которые я обычно пишу) биты данных (скажем, адреса), как правило, отображаются на многих экранах, поэтому это помогает распределять и повторно использовать компоненты представления графического интерфейса.
Но в наши дни вам действительно нужно тщательно подумать, нужно ли вам делать это с нуля, по крайней мере в старых добрых скучных приложениях для отображения и манипулирования данными. Там много всего, и если вы используете инструмент, вы должны идти по его шаблону. Борьба с инструментом контрпродуктивна.