@MaxElc30 янв 2009 в 00:28

Ruby on Rails шаг за шагом. #3 Контроллер и Вид

5 мин

20K

Программирование *

Комментарии 20

@VolCh 30 янв 2009 в 02:23

>Чтобы создать что-нибудь в RoR, нужно идти в командную строку

Смущает слово «нужно»? А ручками создать файлы нельзя?

@MaxElc 30 янв 2009 в 02:32

Эмм… Здесь я имел в виду что-то серьезное :) вроде контроллера, модели. Сейчас поправлю

@VolCh 30 янв 2009 в 05:42

Ну да, файл контроллера из 5-ти строк или вида из двух это очень серьезно и практически невозможно создать ручками :)

@xaerom 30 янв 2009 в 05:47

Да тут дело скорей не в том что сложно, но зачем, если есть полуавтоматические средства? А ручками все потом надо подкрутить и радоваться, что генераторы избавили от ненужной рутины :)

@VolCh 30 янв 2009 в 06:23

Ну, как вариант, из одного проекта можно (или нельзя?) просто скопировать файлы в другой, а не генерировать, а потом копипастить их содержимое.

@dsCode 30 янв 2009 в 10:28

> А ручками создать файлы нельзя?

Правило Генерации: «Избегайте ручного ввода кода, при любом удобном случае пишите программы, которые бы писали программы.» (С) «Философия UNIX».

@mshakhan 30 янв 2009 в 06:57

controllers: интерфейс и деловая логика

Меня что-то смущает эта сторчка. Деловая логика вроде бы должна в большинстве своём содержаться в модели, а интерфейс (если вы имеете в виду интерфейс пользователя) — в представлении.

@Davert 30 янв 2009 в 14:20

бизнес-логика всегда в контроллере, что вас смущает? Работа с данными в модели. Интерфейс наверное имелся ввиду не пользовательский, а интерфейс доступа к данным, я так понимаю.

@miros 30 янв 2009 в 15:19

Бизнес-логика в контроллере — это в корне неверный подход. Разделение: модель — данные, контроллер — логика работы с ними — это заблуждение, сформированное некоторыми туториалами по популярным фреймворкам, в которых такое разделение введено только лишь для простоты объяснения механизма MVC. На самом деле вся бизнес-логика должна размещаться в слое домена (то есть предметной области). Именно объектами этого слоя и манипулируют контроллеры, выполняя второстепенные сервисные действия, такие как создание, поиск и удаление объектов домена, авторизация и проверка данных (это спорно, очень многие относят это тоже к домену). Вообще, чем меньше кода в контроллерах тем лучше. Вся логика должны быть в объектах предметной области. Именно этот слой должен взаимодействовать с моделью данных путём делегирования либо, вообще, сливаться с ней полностью или частично, объединяя логику и механизмы персистивности (Active record).

@Exabiche 30 янв 2009 в 20:33

Ух ты как круто, а где об этом можно в подробностях почитать?

@miros 30 янв 2009 в 20:56

О чём именно? Если о том как работать с бизнес-логикой то есть отличная книжка Eric Evans Domain-Driven Design. Наверное, в ней не со всем можно согласиться, но читается она очень интересно.

@einzam 30 янв 2009 в 20:40

Не совсем с вами согласен, все зависит от задачи.

@Polosatyi 9 апр 2009 в 13:52

Ну когда же продолжение?

@MaxElc 9 апр 2009 в 16:20

Сейчас времени маловато… :( Если и буду писать, то в рамках серии капель о Руби или что-то вроде отдельных кусочков инфы о Rails, потому что разжевывать все с нуля получается с трудом :( Вобщем, если поддержите и настоите на продолжении — то, возьмусь снова ;)

@Polosatyi 10 апр 2009 в 06:42

Моя мама говорит, что любое дело надо доводить до конца :) Я Вас морально поддерживаю и даже смог бы предложить посильную помощь. Например, соавторство.