MVC епта

Почти. Модели не только для обращений к БД, там должна быть вся логика. Контроллер это по сути клей между моделью и видом.

http://stephenwalther.com/archive/2008/08/24/the-evolution-of-mvc

фреймворк можешь посоветовать на пыхе, который наиболее востребован на рынке труда и в котором этот паттерн наиболее верно выполнен?

я понимаю эту хрень так

v - тут тупо отображаем, то что нам передал контроллер, никакой логики тут нет, просто отображаем данные

c - каждый action не больше 20 строчек, простая логика в нем, достали что то, передали, ошибки показали, редирект сделали если нужно, бла бла

m - тут все что с базой связано и сохранением

r - репозиторий, - сюда вытаскиваем громоздкие операции работы с моделью, специфики, каких то особых случаев

l - либы, тут делаем все, что можно переиспользовать, так же тут находится то, что к модели отношение не имеет

symfony лучший

Модели не только для обращений к БД, там должна быть вся логика.

Спорное утверждение. Я, например, предпочитаю, чтобы в модели была только вся абстракция организации данных, а вся логика — в контроллере. Тогда легко менять одну модель на другую, не переписывая логику.

То что ты делаешь это плохая практика, а не спорное утверждение. Модель должна быть отделима от фреймворка, а контроллеры должны быть легкими.

фреймворк можешь посоветовать на пыхе, который наиболее востребован на рынке труда и в котором этот паттерн наиболее верно выполнен?

Востребован Laravel. Наиболее верно в Symphony/Zend + Doctrine.

Модели не только для обращений к БД, там должна быть вся логика.
Модель должна быть отделима от фреймворка

У тебя фреймворк не занимается БД или как?

http://fabien.potencier.org/what-is-symfony2.html#is-symfony2-an-mvc-framework

Зависит от фреймворка. Zend, например, не занимается.

А к чему вопрос?

К срачу конечно. Ну и интересно, нестыковка получается.

Если фреймворк занимается БД, а у тебя обращение к БД в модели, это как? Пишешь свою логику для БД, отдельно от фреймворка?

Или таки завязываешь модель на фреймворк? Но тогда как это вяжется с «модель должна быть отделима от фреймворка»?

Я, например, предпочитаю, чтобы в модели была только вся абстракция организации данных, а вся логика — в контроллере.

О, я знаю откуда такая шиза прёт. Это из-за того, что модели для ORM слишком низкоуровневые (тупое отображение табличек), поэтому для бизнес-логики так и хочется навернуть ещё один слой абстракции. Чтобы не добавлять сложности делают толстые контроллеры, которые по сути и есть M, а модели в такой шизе - это просто DAL. Вот если быдло-орм выкинуть, то всё становится на свои места и архитектура упрощается.

Because I really don't care whether Symfony2 is MVC or not. Probably because the MVC word is so overloaded and because nobody implements exactly the same MVC pattern anyway. The separation of concerns is all I care about.

о чем и речь, мвц для меня ровно тоже самое, разделение мест куда кидать код

Пишешь свою логику для БД, отдельно от фреймворка

В идеале так и надо делать, независимо от того, что там фреймворк предоставляет. Мешать бизнес-логику и логику доступа/хранения (как все эти ваши фреймворки предлагают) - это песдец в перспективе.

l - либы, тут делаем все, что можно переиспользовать, так же тут находится то, что к модели отношение не имеет

Helpers and Utils.

дели не только для обращений к БД, там должна быть вся логика.

Толстая модель - признак плохого кода.

MVC ныне каждый понимает по-своему. Сильно не пытайся разобраться, потому что у каждого суслика свои определения. По сути это баззворд. Можешь изучить SmallTalk, тогда поймёшь изначальный смысл MVC. Только вряд ли тебе это сильно поможет разобраться в твоём PHP-фреймворке.

Спорное утверждение. Я, например, предпочитаю, чтобы в модели была только вся абстракция организации данных, а вся логика — в контроллере. Тогда легко менять одну модель на другую, не переписывая логику.

А ящитаю что нужна четвёртая сущность — `сервис`, в котором вся логика, тогда можно будет ещё легко заменить вьюхи на апи.

Толстая модель - признак плохого кода.

Но лучше, чем толстый контроллер.

Мешать бизнес-логику и логику доступа/хранения (как все эти ваши фреймворки предлагают) - это песдец в перспективе.

Ты упоролсо, фреймворк по определению не может мешать бизнеслогику и хранение данных. Потому что хранение данных реализовано внутри фреймворка, а бизнеслогику ты пишешь отдельно сам.

https://ru.wikipedia.org/wiki/Model-View-Controller#.D0.9D.D0.B0.D0.B8.D0.B1....

Если фреймворк занимается БД, а у тебя обращение к БД в модели, это как? Пишешь свою логику для БД, отдельно от фреймворка?

БД занимается ORM. ORM может существовать отдельно от фреймворка. Так что писать логику отдельно от фреймворка не проблема.

Или таки завязываешь модель на фреймворк? Но тогда как это вяжется с «модель должна быть отделима от фреймворка»?

На самом деле в реальной жизни тебе вряд ли понадобится менять фреймворк, оставляя те же модели. Тем более есть фреймворки со встроенными ORM. Но правильно это когда «модель должна быть отделима от фреймворка».

Модель должна быть отделима от фреймворка

Зачем? При переходе на другой фреймворк всё равно придётся переписывать. И модель, и логику, если она будет в модели.

Вот замена модели внутри фреймворка — дело на практике частое. Скажем, захочу я сменить MySQL на MongoDB или плоский статический файл на sqlite. При этом поменяется только источник данных, вся обработка этих данных — остаётся. Так что лучше эту обработку от модели отделять. Она более общая.

а контроллеры должны быть легкими

Почему?

О, я знаю откуда такая шиза прёт. Это из-за того, что модели для ORM слишком низкоуровневые

Как раз, наоборот. Желание засунуть логику в модель возникает при слишком низком уровне модели. Если модель высокого уровня, то зачем туда совать логику?

если быдло-орм выкинуть, то всё становится на свои места и архитектура упрощается.

Если ORM выкинуть, то в архитектуре при грамотном проектировании моделей ничего не изменится. Модели усложнятся, да, но они сущность инкапсулированная и на всём остальном это не скажется.

Мешать бизнес-логику и логику доступа/хранения - это песдец в перспективе.

Собственно, логика своя там во всех трёх компонентах должна быть:

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

А ящитаю что нужна четвёртая сущность — `сервис`

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

Но правильно это когда «модель должна быть отделима от фреймворка».

Правильнее, когда модель должна быть легко заменима на качественно другую модель в рамках одного фреймворка.

Да потому. Посмотри мои предыдущие ответы, я приводил ссылку на википедию.

Вот замена модели внутри фреймворка — дело на практике частое. Скажем, захочу я сменить MySQL на MongoDB или плоский статический файл на sqlite. При этом поменяется только источник данных, вся обработка этих данных — остаётся. Так что лучше эту обработку от модели отделять. Она более общая.

Если ActiveRecord - наследуешься от другого класса и все. Если DataMapper, то автоматически в IDE меняешь класс менеджера соединений.

Если у тебя весь код в моделях, то один и тот же метод модели ты можешь использовать в разных контроллерах. В случае с толстыми контроллерами придется переписывать все контроллеры, а не пару методов в модели. И ты просто не сможешь заменить модели и оставить тот же контроллер, они просто не подойдут друг к другу.

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

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

ни то не другое нереально в практике, а смена фреймворка в рамках пхп крайне бессмысленна, обычно стеки меняют

я приводил ссылку на википедию.

В вопросах спора о нечётких терминах Вики абсолютно неавторитетна :)

B или плоский статический файл на sqlite

Если ActiveRecord - наследуешься от другого класса и все.

Ну какой ActiveRecord с плоским текстовым файлом? :) Ты уже закапываешься в структуру модели, разкапсулируя её потроха. И это плохо. Замена модели не должна приводить к анализу её структуры.

И вообще я не видел, что бы кто-то в здравом уме менял одну СУБД на другую

Значит, не работал с длительное время развивающимися проектами :) Чего там только не бывает...

А вот смена фреймворка вполне реальна.

Смена фреймворка всё равно приведёт к смене модели. Поэтому может не рассматриваться в нашем частном случае :)

ни то не другое нереально в практике

Я бэкенды менял в своей практике много раз :) Более того, ассортимент бэкендов даже в рамках одного проекта обычно существует. Скажем, списки параметров, одни могут браться из БД, другие — из YAML. Понадобилось админам редактировать — перевели из YAML в БД. Меняется только сама модель. Понадобилось редактору править код странички на десктопе в Zim-wiki — меняем бэкенд с MySQL-таблицы на Zim-файл. И снова меняется только модель. Вся логика работы с ней остаётся прежней.

В JS поменять Restify на Express — вполне реальный юзкейс.

Значит, не работал с длительное время развивающимися проектами :) Чего там только не бывает...

Проект где текстовый файл вместо БД? Это тогда и не проект вовсе, а утилита на коленке.

Ну какой ActiveRecord с плоским текстовым файлом? :) Ты уже закапываешься в структуру модели, разкапсулируя её потроха. И это плохо. Замена модели не должна приводить к анализу её структуры.

Ну и вообще это не модель тогда. Говнокод для работы с файлами будет прям в контроллере, какие тут модели. Не надо в крайности.

Я, например, предпочитаю, чтобы в модели была только вся абстракция организации данных, а вся логика — в контроллере. Тогда легко менять одну модель на другую, не переписывая логику.

2 чаю вам!

Проект где текстовый файл вместо БД? Это тогда и не проект вовсе, а утилита на коленке.

Обоснуй.

Говнокод для работы с файлами будет прям в контроллере, какие тут модели

С чего, вдруг? Модель инкапсулирована. Что там внутри возвращает данные контроллера не касается.

Говнокод для работы с файлами будет прям в контроллере, какие тут модели

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

Обоснуй.

Как я могу тебе что-то обосновать, если ты упоротый?

Да хрень этот mvc, забей, все равно все его а) понимают по своему и б) нарушают даже в рамках своего понимания. Просто не суй логику в шаблоны и разноси бизнес логику с низкоуровневой логикой доступа к субд и все будет хорошо.

Это вполне осуществимо, если зависит от абстракции.

Гениальный кстати подход, как в gentoo виртаульные зависимости в пакетах.

Например пакет virtual/editor - зависимость от абстракции, а не какого-то отдельно взятого редактора.

В итоге, все сводится к задачам управления (внедрения) зависимостями - virtual: model, controller, view ...

Я читаю ваши посты про «тонкую» модель и сразу вспоминаю это - https://ru.wikipedia.org/wiki/Model-View-Controller#.D0.9D.D0.B0.D0.B8.D0.B1....

Прокомментируете? Не наезда ради, действительно интересно. Спор между любителями толстых и тонких контроллеров напоминает войну тупоконечников и остроконечников, но от этого менее увлекательным не становится. По сабжу: модель - это, грубо говоря, класс, с полями _и_ методами, в которых содержится бизнеес-логика, а не просто CRUD-обертка вокруг БД. У вас же как будто получаются классические «Толстые Тупые Уродливые Контроллеры» (привет, Joomla). Это нехрошо с точки зрения ООП (мы же считаем, что MVC это все же около-ООП паттерн? По крайне мере, я не встречал реализаций для других парадигм).

модель - это, грубо говоря, класс, с полями _и_ методами, в которых содержится бизнеес-логика, а не просто CRUD-обертка вокруг БД.

В хороших домах все ровно с точность до наоборот, за бизнес логику (окромя какой-нибудь перегрузки toString() или equals()) в модели данных бьют железной линейкой по пальцам. Если есть сложная логика работы с базой - выносим ее отдельно, в какие нибудь репозитории. Не тривиальную бизнес-логику тоже по хорошему вытаскиваем в отдельный сервисный слой. Тривиальную типа валидации можно оставить и в контроллерах.

Прочитал тред, понял, что точно не останусь без работы.
Капча: 228 (-;

не вкуриваю в чем понт этого паттерна...

Учитывая, что у вьюх уже давно свои контроллеры и модели, классический MVC давно протух. Иначе не было бы MVVM и прочих 100500 попыток его выпрямить.

Если у тебя весь код в моделях, то один и тот же метод модели ты можешь использовать в разных контроллерах. В случае с толстыми контроллерами придется переписывать все контроллеры, а не пару методов в модели. И ты просто не сможешь заменить модели и оставить тот же контроллер, они просто не подойдут друг к другу.

Не кури этих шишек, куда засунуть логику не имеет никакого отношения к повторному использованию кода. У тебя может быть код отвечающий за преобразование структуры в строку. По твоей шишкологике его надо в модель, а в то время как это часть view, но не прибитая к способы отображения - и типичный пример того что нет простых ответов 8)

скажем так, MVC делался вроде бы для UI а не веба, а в вебе он никогда и не был к месту.

Ну учитывая вопрос про вэб фрэймурки на похапе, понятно насколько там в кассу МВЦ.

Насчет того для сего делался - ну это древнее говно мамонта со всеми вытекающими. Делался он в отсутствие строгой изоляции между компонентами (все в одном exe-шнике), когда можно было почесать левой ногой правое ухо при необходимости. MVVM тоже не для веба появился. Просто на вебе все косяки с херовой изоляцией между бизнес-логикой и логикой представлений вылезли в полный рост.

Есть характерный пример - отображение списка постов. По логике MVC надо клепать запрос, который переклеит посты и авторов, выдав новую структуру для шаблона. А по современному - надо отдать отдельно список постов и список авторов, и клеиться они будут уже в темплейте или в яваскрипте.

Для хранения хоть сколько-нибудь большого количества данных текстовые файлики не подходят в принципе.

1. Ещё раз прошу обосновать.

2. Я нигде не говорил про _большое количество данных_ (что не отменяет первый вопрос)

Как я могу тебе что-то обосновать, если ты упоротый?

Ок, так и сказал бы, что обосновать не можешь и переход на личности — единственный аргумент. Я бы сразу пополнил игнорлист, а не тратил бы на тебя время.

Прокомментируете?

Ну, это реально холивор :) Обоснованный ещё тем, что чистый MVC — это сферический конь в ваккуме.

По сабжу: модель - это, грубо говоря, класс, с полями _и_ методами, в которых содержится бизнеес-логика

Я думаю, что, на самом деле, много непонимания вылезает от нечёткости даже определений составляющих MVC. Типа, что входит в «бизнес-логику», а что не входит. Я поэтому просто рассматриваю для себя модель, логику модели, контроллер, логику контроллера, представление и логику представления :) — MVC епта (комментарий)

У вас же как будто получаются классические «Толстые Тупые Уродливые Контроллеры»

Грешен отчасти. Исторически так сложилось, перекос по инерции. Самый первый вариант фреймворка, лет 15 назад, был не объектным и микроядерным. Потом появились объектные компоненты. Ещё не было «на рынке» термина MVC, но по сути, реализация была именно такая. Модели-агенты, примитивный контроллер, представления-шаблоны. Так вот, модели с логикой управления были так жирны и так часто унифицированы (а «в редакторе настоящего программиста не должно быть функций копирования блоков кода» © Чарльз Мур), что типовые функции стали перемещаться в общий контроллер и скоро микроядерность потеряла смысл — всё равно делала всё объектная реализация. И намного эффективнее. В итоге объектный унифицированный контроллер стал новым ядром системы. А вот дальше была ошибка — он долго по инерции развивался в процедурной парадигме. А, поскольку «работает — не трогай», уйма всякой фигни там процедурной осталась на годы. Но проблема ТТУК решается не отказом от жирного контроллера вообще, а его объектной декомпозицией. Т.е. вместо нынешнего Толстого Умного (почему Тупого? :)) Уродливого Контроллера формируется Рой Тонких Тупых Красивых Компонентов Контроллеров :)

модель - это, грубо говоря, класс, с полями _и_ методами, в которых содержится бизнеес-логика, а не просто CRUD-обертка вокруг БД

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

Но чистоты тут всё равно не достичь даже в рамках голых моделей.

Вот, рассмотрим, для конкретики, простую реализацию форума. Есть модель ForumTopic. Есть модель ForumPost. Кто должен заниматься значением метода LastPost() у ForumTopic? Поручим это дело контроллеру — и это будет нарушением инкапсуляции. Контроллер не должен знать ничего о структуре модели, только о её интерфейсе. Иначе, захотим потом поменять организацию LastPost() в модели, придётся менять логику работы с этим методом в контроллере. Получается, что модель ForumTopic должна сама уметь работать с ForumPost и иметь в себе логику, которая вполне катит по терминологии на «логику контроллера», так как управляет взаимодействиями моделей.

По крайне мере, я не встречал реализаций для других парадигм

Ну, как я писал выше, у меня была реализация практически современного MVC в процедурном стиле :) Но объекты намного красивее, проще и удобнее.