alexey_baranov - как обычно сваливаем на сферических коней в вакууме. В реальной системе, хотя бы построенной на том же зенд фреймворке Zend_Date никогда не будет выступать в виде модели. Потому-то модель там - это не что-то абстрактное, а вполне конкретное. А Zend_Date - вспомогательный класс работы с датой. И нигде в документации по зенду вы не найдете упоменания, что де это модель. Пытаясь смешать все в одну кучу непонятно ради чего - путаете только себя.
MiksIr Модуль - это абстракция, функциональная часть чего-то. Можно обозвать это плагином, plug-in, нечто "подключающееся" =) Я говорил о веб-программировании имея ввиду создание сайтов (порталов). Модуль - это абстракция в первую очередь для пользователей, чтобы им было удобно подключать/отключать части системы. Поэтому это понятие используется в очень многих CMS'ках (от Bitrix до phpnuke). В такой системе, модуль - это как минимум отдельный файл. А если использовать паттерн MVC, то удобно, чтобы модуль был Если так, то нормально, чтобы внутри модуля модели использовали друг-друга. У модуля есть свой интерфес (контроллеры), через который можно с ним работать, корректная работа модуля при использовании в обход этого интерфейса не предполагается. Апд. Пока писал сообщение, придумал определение модулю - "одна или несколько связаных между собой моделей". =)
До-свидания ООП Это уже начинается что-то из серии темы про API форума. Забудьте про модули вплоть до того момента, как потребуется оформить готовое уже решение в его виде.
alexey_baranov Жесть. Все это последний мой ответ тебе в теме. Извини, но я с людьми с кашей в мозгах общаться не умею. Вы у меня вызываете жесткий рвотный рефлекс и желание материться. Ну и написал пример ты через ж...у Отличный пример как писать не надо. Запомни, MVC это не Zend_Db, Zend_Controller, Zend_View MVC - это паттерн проектирования. Т.е. подход, который используется для написания кода. Более того MVC не связан с ООП и может быть реализован процедурно! Ты смешал пользовательский и программный интерфейсы. Пользовательский интерфейс в MVC представлен View. В случае CLI версии он мне не нужен, и я использую лишь программный интерфейс, собственно M и С. Взять данные, и обработать их. Для того чтобы не дублировать код, я и использую обработку данных уже единожды написанную в M и C. Глупость. MVC это арихтектура разделения программных сущностей. И ничего более. Модель не обязана содержать бизнеслогику. Она должна предоставлять данные. То что ты пытаешься сейчас рассказать это каша из Domain Model и MVC проекта. Да, в проекте на MVC-архитектуре в качестве Модели может использоваться Domain Model, но не обязательно. Более того, сама Domain Model может быть построена по MVC-архитектуре DAO (Data Access Object) + DTO (Data Transport Object) + DSO (Data Service Object) = DDM (Domain Driven Model) DAO - это источник данных - она же Model. DTO - это представление данных - оно же View DSO - это публичные методы предоставляемые этой моделью, а также методы управляющие DAO&DTO - оно же Controller Но это ровным счетом не имеет никакого отношения к тому, что одна DDM в проекте не должна знать о другой. Парень, еще раз - ты путаешь архитектурное определение и конкретную реализацию. В проекте модели не должны знать о других моделях, просто потому что ты получишь статическую связь в коде, которую можно переписать только одним способом - переписав весь проект. +1
вот чудак-человек. как это он не модель, какой еще вспомогательный класс? кто такой термин выдумал. я такого в терминологии мвц не втречал? как это там в книжке не написано и оно поэтому не должно называться моделью? мвц появилась в 80-ые годы, когда ни zf, ни пхп не было. это только от тебя зависет. как ты сам интерфейс захочешь сделать. если в мвц, то дата в этот момент стала моделью. PHP: <?php class Zend_DateView extends Zend_View{ fnc render(){ return $this->model->getDate(); } } все, дата теперь модель для вьюшки Zend_DateView. контролер написать? PHP: <?php $view= new Zend_DateView(); $view->model= new Zend_Date(); $view->render(); а это откуда знаешь? это сильное заявление. ты весь код в мире сам лично проверил или как ты пришел к такому выводу? у меня дата в интерфейсе всегда модель для своих вьюшек и контролеров. И Date и даже все скалярные типы и массивы- все модели. потому что интерфейс в мвц. на Date две вьюшки. одна когда надо просто отобразить дату, другая для редактирования дат. и один контролер. а упоминание, что это де не модель найдешь? тоже нет. потому что это не задача zf учить что такое мвц. он паттерн не объясняет. считается, что ты уже его понимаешь. если хочешь мвц - это прежде всего smaltalk, там впервые придумали и сказали "мвц", и там весь пользовательский интерфейс в мвц, наверное java swing, и очень хороший м-вц в 1с:предриятие. в них и дата и число и бул - модели для своих вьюшек и контролеров. а ты по каким источником судишь, где мвц, а где сферические кони? я не знаю что ты понимаешь под вспомогательными классами. Например, когда я говорю модели используются в других моделях, имею в виду "в приложении с пользовательским интерфейсом по паттерну мвц неинтерфейсные классы (все кроме вьюшек и контролеров) используют другие неинтерфейсные классы.". а говорю так, потому что для мвц-интерфейса они все модели.
учи мат часть http://en.wikipedia.org/wiki/Model-View-Controller пока что ты говоришь о каком-то своем собственном "мвц", который к настоящему мвц не имеет отношения.
учи мат часть http://en.wikipedia.org/wiki/Model-View-Controller пока что ты говоришь о каком-то своем собственно- изобретенном мвц, который к настоящему мвц не имеет отношения.
Вот тут диллема возникает. Паттерн MVC можно использовать либо как паттерн для всего приложения, либо только для отдельных частей.
Забей. Нет там дилеммы. Использовать надо то, что подходит тебе в данный момент. У нас есть один ......к, не умеющий читать даже то, что цитирует. Контроллер Модель Представление.
alexey_baranov Zend_Date станет моделью только в одном случае - когда вы создадите приложение по управлению системным временем на компьютере. И то, наиболее вероятно, что при этом будет создан отдельный класс modelDate который будет брать данные из Zend_Date как источника. Ваша ошибка в том, что вы оперируете понятием Модель в отрыве от MVC. Нет такого. Модель - четкий элемент MVC который предоставляет данные для View и _управляется_ Controller. Более того, крайне нежелательно для модели как-то интерпретировать данные. Таким образом моделью может быть обертка вокруг time(), а интерпретация (вывод в нужном формате и т.д.) - задача View, возможно с применением вспомогательных классов вида Zend_Date. В своей практике мы называем их хелперами (helper), но это чисто наша внутренняя заморочка, так что не навязываю. В принципе я вас понимаю, почему хочется назвать Zend_Date моделью - вроде как источник данных, ага. Но опять - не каждый источник данных - модель. Ибо так можно и шаблонизатор назвать моделью, ибо он предоставляет нам данные на основе состояния памяти. И Db, Memcached классы назвать моделями, ибо через них тоже данные достаются - из базы, из мемкеша. Если вызывает затрудение разделить модель/не модель и особо пользуетесь фреймворком, руководствуйтесь простым правилом - все, что нужно положить в директорию models - модели, остальное - нет.
Вот тут тоже спорный момент. И споры эти из-за того, что MVC - всего-лишь паттерн проектирования, а не стандарт. MVC возник для разделения данных, логики и представления внутри одного приложения. БД не хочется называть моделью только потому, что это отдельное приложение, а что, если бы оно было инкапсулировано? По-моему, самая настоящая модель Еще есть такая мысль: если отсутствует один из компонентов - модель, контроллер или вид - то это уже не MVC (КО одобрил), а значит часть этой неполноценой системы не следует называть моделью или например контроллером. Т.е. если паттерн строго не соблюдается, то это уже не MVC, а значит можно творить что вздумается, но не обзывать это мвц'шкой =) С другой стороны - если MVC - это основа всей системы, то и Zend_Date может быть моделью, т.к. какой-то контроллер будет получать оттуда данные и отдавать их на представление.
[vs] - вы почти рядом. "Т.е. если паттерн строго не соблюдается, то это уже не MVC, а значит можно творить что вздумается, но не обзывать это мвц'шкой". А вот дальше ошибка, стоит продолжить первую мысль - те классы, которые не являются связкой конкретной модель-контроллер-вью, не могут быть моделью. MVC была придумана для реализации схемы доступа и изменения данных пользователем. Вот то, что есть такая цепочка - есть MVC, а то, что в конкретную цепочку не входит (помните, вы это модулем называли) - это просто прикладные классы. Zend_Date может быть моделью именно если он будет моделью Я не педагог, так что мысль доношу окольными путями. Критерий "для начинающих" - как разлечить модель/не модель в фреймворке я предложил выше
Simpliest Слышешь звон, не знаешь где он. Куда ты лезешь? тармази, уже. Ты же даже на пальцах не понимаешь, что такое мвц. Это видно по твоим постам. ну и в коде тогда естественно тоже самое. Ты что-то сачинил про себя сам с собой, назвал это мвц и думаешь, что это оно и есть. Еще меня и других учишь. Это твой личный отдельный мвц. Назови его тогда по-другому мвг например. Потому что он не ммеет ничего общего с известным паттерном и, кстати он совершает ошибку, от которой учит всемизвестный мвц. МВЦ учит всего одной вещи. Только одной, понимаешь? Это важно. Написано на каждом столбе: отделение бизнеслогики от ввода и отображения. Например он не дает советов, как должны взаимодействовать или не взаимодействовать классы внутри бизнеслогики, и что ты там еще придумал- это все опять твои тараканы. для этого есть другие паттерны. И второе: классы бизнеслогики становятся моделями в мвц. Бизнеслогику в контролеры ни нагой! Поэтому то, как ты пишешь- это анти-мвц. Учи мат. часть. Я тебе могу сто ссылок привести, но найди сам. тебе надо.
Слушай друг, я же табе русским языком написал что для даты есть две вьюшки и один контролер. А ты мне отвечаешь, что модель Дата в отрыве от MVC. Читай внимательнее. И все же ответь на мой вопрос, про который я спросил в прошлый раз, по каким источникам кроме zf судишь где мвц, а где сферические кони?
да ты что, а кто? ты нашел его уже? а ты знаешь, что ты лично пользуешь мвц каждый день по сто раз? ты пользуешь зф? даже без вьюшек и контролеров? так вот весь zf и даже класс Zend_Date написан в МВЦ! прикинь да. ОРМ какой-нибудь пользуешь? все серьезные ОРМы тоже написаны в МВЦ. дактрина например точно. PHPExcel пользуешь? он тоже весь в мвц. Почти все серьезные библиотеки, которые часто повторно используются написаны в мвц. Ты их используешь каждый день. Они все мвц., просто ты этого не понимаешь. Ты наверное думаешь, что мвц- это все эти фронт-контролеры раутеры и диспетчеры и вьюшки и хэлперы и прочая шняга из Zend Freamworkf, да? вот это думаешь и есть мвц? Нет. мвц- это просто паттерн который появился задолго до пхп. он просто говорит "ребята, делайте бизнеслогику отдельно от ввода (на пхп это $_GET, $_POST, $_REQUEST... ) и представления(на пхп это echo, ptint и все такое)". если бы все те библиотеки, про которые я сказал, были бы написаны не в мвц, мы бы с тобой повесились. к примеру был бы вот такой замечательный класс Zend_Mail PHP: <?php class Zend_Mail{ fnc send(){ if(!mail_send($subject, $body)) echo "Mail error: ".mail_error_code(); } } или вот такой замечательный класс ОРМа. Его наверное Simpliest написал, он любитель бизнеслогику в котролеры засунуть. PHP: <?php class Doctrine_Record{ fnc load(){ $pdo->query("select * from table where id={$_GET['model_id']}"); } } вот эти два класса уровня бизнеслогики написаны против правил мвц. ты хочешь чтобы все классы были так написаны? если нет, то не говори, что мвц кем-то искусственно навязан. а я такие классы видал в интернете много раз. ламаки понапишут, потом их переделывай.
Можно. Я этот бред уже читать не могу... Но придут неокрепшие мозги, и прочтут нашего оратора - мастера орального искусства. И начнут писать код с которым регулярно будешь иметь удовольствие. Убейся чудо - mysql_query, mysql_fetch_assoc - тоже могут быть вводом. http://en.wikipedia.org/wiki/Model http://en.wikipedia.org/wiki/Domain-specific_modelling http://en.wikipedia.org/wiki/Business_logic Попутно ознакомся еще с источниками твоей каши http://en.wikipedia.org/wiki/Multitier_ ... chitecture http://en.wikipedia.org/wiki/Domain_engineering http://en.wikipedia.org/wiki/Domain-driven_design http://en.wikipedia.org/wiki/Model-driven_architecture А еще настоятельно рекомендую ознакомится с "рекомендациями" Zend почему не стоит использовать Модель в Представлении или из Представления обращаться к Контроллеру (хотя MVC это позволяет в виде неявных связей) Маразм крепчал. Дочка, а ты в курсе что кроме MVC есть еще такая вешь как 3-tier architecture? Которая тоже описывает механизм функционирования распределенных систем.
Здесь никто не пользуется МВЦ только ради МВЦ. Есть куча рекомендаций и практик о которых тебе талдычут, и одна из них - уменьшение сцепок. Для моделей это особенно важно. И никто не говорил, что МВЦ запрещает использовать модели одна внутри другой, говорили что просто так делать нельзя, а если у тебя заворот мозгов, что кроме МВЦ ничего воспринимать не можешь - досвидания. Извини, не знал, что ты разрабатываешь приложения "нажми на кнопку - получи какая сегодня дата".
Ух ты и ламерьё. Обаснованый ламак. Гроза малолеток. Какая я тебе дочка? ..й на рот положить? узнаешь кто здесь дочка. Читай внимательней, там дальше все по тебя. 1. Паттерн Domain-driven_design 2. Паттерн 3-tier architecture 3. Паттерн MVC Две первые картинки чем-то смахивают на мвц. И тут три уровня и в мвц три уровня. Тут Presentation и в мвц представление. Tyт Data Layer по-твоему в мвц соответствует моделям, из чего ты заключил что оставшийся Bisnes logic layer- это контролеры. Ламерье! Это твое умозаключение привело к появлению никому неизвостного даселе паттерна, по которому бизнеслогика должна содержаться в контролерах! То есть все наоборот. Это объясняет почему ты написал Этот новый паттерн я называю паттерн симплиаттерн в честь тебя ламак. Определение симплиатерна- барматуха из трех паттернов, где модели одного отображаются в модели других, представления в представления, а бизнеслогика в контролеры. Ну да падем теперь поговорим о твоем коде. Код у тебя должно быть отображает билеберду в твоей голове. Однозначно, что ты слил всю бизнеслогику в контроллеры согласно Симплиаттерну и сломал себе весь мвц. Совершил все типичные ламерские ошибки. И делаешь ты это классами zf вьюшек и контроллеров, и поэтому это особенно смешно, для всех кто в этом разбирается. Помнишь ты свое ламерское мнение навязывал остальным, когда крон-скрипт через Zend_Front_Controller, потому что не хочешь дублировать код? Вот и эти концы сошлись в общую картинку. Конечно, а тебе без контроллеров- то уже никак. Ты всю бизнеслогику по Симплиаттерну размазал на контроллеры. И проделал это мвц-шными классами. Я валяюсь! Эти классы были спецально придуманы для того, чтобы отделять бизнеслогику от контроллеров. ну нет предела твоей тупой упертости диагноз твой неутешителен. в голове у тебя каша из паттернов Симплиаттерн. ты пишешь ламерский код, который совершает типичные ламерские ошибки, не позволяющие повторно использовать код. Ты самоуверенный ламак- самаучка, это развернутое обоснование. Забудь дарогу в темы про мвц. начинай с самого начала читать азбуку.