чтобы делить на тройки мвц не надо включать ум. это тупая однообразная работа. включаешь броню и как на станке штампуешь одно и то же. модель- вьюшка- контролер. опять модель- вьюшка- контролер. везде один и тот же принцип. тупая и однообразная работа и никакого творчества. сто человек спроси разделить на тройку, и все сто разделят одним образом и совсем ломак и профессионал, потому что например бизнеслогика и в африке бизнеслогика и никогда не станет отображением. где голову придется ломать, так при разработке хороших моделей. здравствуй консольное приложение.
есть пагер, который пагерит данный по странично. Есть вьюшка, которая отображает пагер. Есть контралер, который как бы сообщает пользовательские хотелки (нажал на номер страницы, нажал на заголовок колонки) модели. в чем разница с тем что ты написал. 1. пагер, если это пагер не получает на входе порядковый номер первой строки и количество строк, начиная с нее. То что ты описал- это больше похоже на окно данных. Тем что ты описал можно получать например 10 строк начиная с десятой. 25 строк начиная с десятой. 100 строк начиная с десятой. Пагер так не умеет. Пагер выдает порции данных одинакового размера по порядку. То есть с 1 по 10, с 11 по 20, с 21 по 30 или с 1 по 25, с 26 по 50ый и т.д. Чувствуешь разницу? 2. передавать надо не массив данных, который подготовила модель, а саму модель. Разницу улавливаешь? Передав модель, ты передаешь сразу и текущую страницу, и размер страницы, и сам набор данных страницы, и методы для определения общего количества страниц и общего количество строк и все остальное. все это тебе пригодится во время отрисовки пагера. если бы ты передал только набор, у тебя опять возникнут вопросы. например, а как выделить цветом номер текущей страницы? а может создать во вьюшке поле для сохранения страницы и заполнять его перед рендеренгом? а как потом узнать обще количество объектов чтобы при необходимости написать "10 из 412"? опять создавать поле? уже даже подсознательно можно почувствовать, что начинается какая- то лажа. Если все делать правильно, мвц не будет как бы привносить дополнительную сложность в код. есть модель и есть вьюшка модели, вьюшка рисует модель. модель хранит данные и всю логику обработки этих данных. вьюшка получает модель и рисует ее. все просто и естественно. оно везде так же. не думай. включай броню. Сделал пагер- отдай его вьюшке. 3. почему контролер делает модель и потом передает ее вьюшке и т.д.? кто сказал, что все работает в контролере? это может быть просто файл из 5 строк.
Конечно, все это может быть и в контролере, равно как и не в контролере. Заострил внимание, потому что некоторым настойчиво кажется, что если какая- то библиотечка есть МВЦ и используется в каком-то МВЦ проекте, то это как приговор. ее можно использовать только в каких- то других контролерах, специальных моделях и все. Это не так. Можно, например, безболезненно выкинуть из нее все контролеры и все вьюшки и использовать оставшиеся модели в проектах с не мвц-шным интерфейсом или вообще в консольных программах. Конечно, при условии, что функционал поделен правильно.
Дак потому что это один из самых важных принципов MVC. Модель не должна ничего знать ни о контроллере, ни о виде. А вот отделение вида от контроллера уже не так важно. Как видно связь с моделью только в одном направлении.
да да, все это и даже чуть- чуть больше. больше в том, что можно безболезненно выкинуть из тройки только контролер. при этом получится что пользователя как бы отрезали от модели, но ничего не сломается. в случае с пагером будет нарисована страница данных и все управляющие элементы как колонки, на которые можно нажать для сортировки, номера страниц, на которые можно нажать для перехода и все остальное как обычно. но если нажимать по колонкам или страницам, ничего происходить не будет. как была первая страница данных, так и останется. какой был порядок таким и останется. я свой пагер так и писал. сначала модель. протестил ее в консольке, потом вьюшку. протестил чтобы рисовала правильно. тыкаешь- тыкаешь ничего не работает. и только потом уже контролер. вьюшка без контролера всегда прекрасно работает. как пользователя от модели отрезать. контролер без вьюшки часто нет.
что есть орм? почему только в одном - а в обратном то? Модель же передает контроллеру данные или виду... Или тут стрелками направление команд написано? alexey_baranov извини Леха, но я уже опять против тебя, потому, что как ты говоришь абстрагироваться консольным приложение и будет голая модель немного не верное выражение. А не верное оно потому что сама по себе модель ничего вообще не сможет сделать, ею надо кем-то управлять, то есть в любом приложении существует контроллер: любой, даже самый маленький, который явно даже может не просматриваться и присутствовать по умолчанию...
орм == ORM Сама модель ничего не передаёт контроллеру. Контроллер может попросить модель выдать ему нужные данные.
?, а как же Может так лучше: Сама модель ничего не передаёт контроллеру. Контроллер может попросить модель выдать представлению нужные данные.
Данные не обязательно пойдут в представление. Их можно по почте, например, отправить или записать в файл.
Вот если взять этот пример "консольного" приложения. main.php PHP: class Conroller { public static function default() { $pager= new Pager(); $pager->number_of_users=25; $pager->page= 7; $view = new View($pager); $view->render(); } } class View { public function redner() { foreach($pager->getPage() as $user) fwrite($f, $user->getName()); } } Conroller::default(); } Получается, что конроллер и представление никуда не выкинулись.
Что такое контролер? Это какой- то класс, который передает модели пользовательские действия. "явно даже может не просматриваться и присутствовать по умолчанию" - это не про контролер. мистики то тут никакой нет. или этот класс есть и тогда говорят, что контролер есть или его нет, тогда говорят, что контролера нет. Никакой двузначности тут никогда не было и не должно быть. А модель без контролера прекрасно живет. ей вообще по-барабану. она все знает и все умеет делать. если ты отнимешь от нее контролер, она как бы останется отрезанной от пользователя и только. ты прав в том, что модель, ни с того- ни с сего, сама не может изменить свое состояние. кто- то должен ей приказать. а кто же ей это приказывает сделать? контролер? да, бывает и контролер. но чаше всего другая модель. становится ли другая модель в этот момент контролером для той модели? нет, это по-прежнему модель. просто одна модель использует другую модель. это и есть любое консольное приложение.
никогда. Если у тебя такое происходит, это в корне неверно. Модели не должны иметь никаких связок напрямую между собой.
:shock: нет сил комментировать это. по- моему перед тем, как юзать сложные мвц фреймворки, надо немного набить руку в мвц. для этого больше подойдет написание вьюшек и контролеров для строковой переменной или целого числа.
неверно твое представление об мвц. если то что ты говоришь имеет хоть какое- то обоснование, поделись с нами.
принцип -то в мвц везде один и для сложных моделей и для строковой переменной. надо только один раз его уловить. вот, к примеру, ты можешь использовать строковую переменную в консольном приложении. типа так: PHP: <?php $str= 'asdfas'; $str2= $str; это и есть использование голой модели. но этого не достаточно чтобы сделать пользовательский интерфейс. Теперь если тебе попросят а покажи мне чему равно $str, то следуя логике мвц ты напишешь вьюшку. она очень простая, соль у нее будет такая: PHP: <?php echo htmlspecialchars($this->model); это уже вьюшка. ты уже сможешь просто использовать строку как раньше и сможешь ее отобразить, когда надо. И последнее тебе придется как- то связать ее с действиями пользователя.То есть если пользователь ввел что- то в поле для ввода, это должно попасть в строку. Для этого следуя мвц и пишут контролер. Для строки тоже очень простой, типа PHP: <?php $this->model= stripslashes($_REQUEST['string_input']) вот и все. ты добился разделения лигики, представления и пользовательского управления. Это подтверждается тем, что ты можешь писать в графическом пользовательском интерфейсе, а можешь выкинуть представление и контроллер, писать просто в моделях и у тебя ничего не сломается.
все это прекрасно. ортогональность- это бацкая весчь. кстати единственное преимущество мвц в том, что бизнес-логика, пользовательское управление и отображения становятся ортогональными. я за. только причем тут это? где обоснование того, что "Модели не должны иметь никаких связок напрямую между собой."? ты наверное думаешь, что ортогональность мвц заключается в том, что в мвц модели несвязны между собой. а на самом деле мвц всего лишь отделяет модель от пользовательского интерфейса. это написано на каждом столбу. в этом заключается ортогональность мвц. мвц никак не меняет и не перепроектирует сами модели и не дает никаких советов на эту тему.
Хорошо, начнем с того, что я неверно выразился. Скажем так: Модели из разных предметных областей не должны взаимодействовать напрямую, это противоречит принципу низкой связанности. Так лучше?
alexey_baranov, а кто как не контроллер будет управлять моделью. Даже если как ты говоришь модель управляет моделью, то кто будет управлять вот этой управляющей моделью? Ведь сама модель не может себя вывести на экран и не может принять данные от пользователя. Дак какой от неё толк без контроллера?
опять не угадал. желательно чтобы модели вообще не взаимодействовали друг с другом. неважно из разных они областей или из одной. Даже если они из одной предметной области, все равно желательно. Это всегда уменьшает связность. Однако нельзя никогда сказать что кто- то не должен взаимодействовать с кем-то. нет как бы такого строгого правила. хотя конечно все к этому стремятся насколько можно. это очень окупается со временем. Вообще ортогональность моделей никак не относится к мвц. это как бы отдельная тема за рамками мвц. мвц помогает разрешить ортогональность пользовательского интерфейса. для этого был придуман, для этого и используется. к примеру проект может быть на пятерочку с точки зрения мвц , и одновременно с этим неуд с точки зрения ортогональности моделей. понимаешь?