Комментарии 19
НЛО прилетело и опубликовало эту надпись здесь
ммм… не совсем понял вопрос, моделью в MVC называется модель :)
НЛО прилетело и опубликовало эту надпись здесь
модель хранит данные, это состояние системы на конкретный момент времени (если можно так выразиться)
НЛО прилетело и опубликовало эту надпись здесь
управляет моделью?
обрабатывает данные модели и готовит их к представлению, обрабатывает пользовательские действия
НЛО прилетело и опубликовало эту надпись здесь
Контроллер
НЛО прилетело и опубликовало эту надпись здесь
Нет. Никто ниче не путает. Может сформулировать не может это другое дело. Ведь маппинг может отражать таблицу как обьект а не только сущность в таблице как обьект. Вы осветили лишь часть орм. Так что ORM может иметь полное права отвечать за модель в целом
И касательно интеграла… это явно не модель, параметры от пользователя не должно там быть. Это либо стороняя библиотека некий хелпер либо контролер с применением этой либы. Например в doctrine есть такое понятие как template вот если уже интеграл вычиялть на стороне модели это как раз он и будет. Но к сущности он не имеет никакого отношения.
И касательно интеграла… это явно не модель, параметры от пользователя не должно там быть. Это либо стороняя библиотека некий хелпер либо контролер с применением этой либы. Например в doctrine есть такое понятие как template вот если уже интеграл вычиялть на стороне модели это как раз он и будет. Но к сущности он не имеет никакого отношения.
У меня такое ощущение, что вы занимаетесь троллингом.
Я уверен _в том_, что получение данных и вычисления на их основе _должен_ выполнять контроллер, а не модель, хотя в ней, разумеется, это тоже возможно.
Я уверен _в том_, что получение данных и вычисления на их основе _должен_ выполнять контроллер, а не модель, хотя в ней, разумеется, это тоже возможно.
Раньше ломал на этот счет голову. Ясность пришла только после прочтения «архитектуры корпаративных приложений» Фаулера.
Если вкратце, то есть 2 подхода:
1) Flat Controller, это когда модель отвечает только за сохранение, а бизнес в контроллере.
2) Thin Controller, бизнес логика в модели.
В рельсах принят 1-й способ, но второй более правильный. Фактически в рельсах упразнили слой сервисов, что и стало причиной «толстых» контроллеров.
MVC это общая концепция отделения представления от БЛ. Совсем не обязательно наличие одноименнх классов. Мне вот больше ближе «трехзвенка» (бд->сервисы->контроллер<->ui), в этой схеме ui не имеет прямого доступа к БД.
Если вкратце, то есть 2 подхода:
1) Flat Controller, это когда модель отвечает только за сохранение, а бизнес в контроллере.
2) Thin Controller, бизнес логика в модели.
В рельсах принят 1-й способ, но второй более правильный. Фактически в рельсах упразнили слой сервисов, что и стало причиной «толстых» контроллеров.
MVC это общая концепция отделения представления от БЛ. Совсем не обязательно наличие одноименнх классов. Мне вот больше ближе «трехзвенка» (бд->сервисы->контроллер<->ui), в этой схеме ui не имеет прямого доступа к БД.
НЛО прилетело и опубликовало эту надпись здесь
в идеале
make_resourceful do
build :all
end
make_resourceful do
build :all
end
Почуствовует?
Полезно, спасибо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ActiveModel: пусть любой Ruby объект почувствует себя ActiveRecord