Не понял. Откуда у тебя появляется дополнительная валидация? что такого ты валидируешь через веб-интерфейс, чего не валидируешь в cli? Чего вдруг? А сегодня к твоему проекту подключили мой Math::div(), который работает и с комплексными числами тоже. И учитывая ограничения PHP, представлены они у меня строками, например ("15-1" это 15*sqrt(-1)) А ты взял в контроллере и решил что "15-1" невалидно... Гениально.
Simpliest какие глупости? Ты сказал что модель должна, я говорю что не должна. То что она должна это твое личное субъективное мнение - ты мне это выше сказал. Не надо строит их себя умника, указывая, что я говорю глупости. У каждого своя логика - да с этим можно согласится и поставить точку. А вот насчет глупости тут явно спорный вопрос.
Мне вот кажется, что ситуация с городом и фирмой, как раз такая, когда контроллер, а не модель фирмы, может и должен проверять данные. Мы добавляем фирму, в контроллер приходят данные о названии и городе в котором она находится (допустим приходит id-города). Контроллер вызывает проверку существует ли такой id в таблице города. И если существует проверят валидность названия фирмы и записывает фирму. Если нет выводит ошибку. По-моему, логично и модели не связанны между собой. (хотя возможно в данном случае модель фирмы можно рассматривать как модель которая без модели города не может существовать и следовательно в ней можно проверять и валидность id города вызывая валидацию модели города). уф... надеюсь не сильно замутно описал.
Да говори на здоровье. Кто-то мешает тебе говорить глупости? Ты лишь подтверждаешь мою точку зрения Вот ты у нас модель, если ты определяешь какие данные(правила работы) для тебя правильные (должна/не должна), то ты занимаешься валидацией. Но по твоей же логике, ты этого не должен делать, поэтому валидировать(решать что для тебя правильно) будем мы. А ты будешь нервно курить в сторонке. Дошло?
Все правильно. С одним лишь исключением - Он проверяет не данные! А правильность связи. Т.е. он берет id города у модели Фирма. И при помощи модели Город, валидирует этот id. Что id правильный - знает только Город. А вот откуда взять и кому дать на валидацию - знает Контроллер.
дошло, только в моем случае командует вами и мной один шеф - цель! Если вы слукавите, цель не сработает и я всё равно буду спокойно себя чувствовать... На то у меня и не ваша логика разделения (см. выше)
да я не спорю, что можно и через ZF-ные контролеры модель дернуть, если сэмулировать вызов. ты мне скажи просто, если сейчас надо будет написать крон скрипт, который удаляет старые объекты из базы, ты это через Фронт_Контролер, Раутер и Контролер с акшином напишешь, как писал выше?
Да. Потому что в таком случае мне не придется писать отдельно функционал для веб. Я смогу пользоваться где угодно одним и тем же кодом.
Simpliest и если вот сейчас встанет задача разослать всем клиентам какое-то информационное письмо, тоже через Fron-> Router -> Controller будешь делать ?
что такое модель вобще? модель- это все что угодно любой прикладной класс. Например Zend_Date или Zend_Config- это две хорошие модели. Конечно, модель используется внутри других моделей. Почему это кого-то удивляет? На моделях я могу написать веб-сервис и скажем консольное приолжение или сокет-сервер или все что угодно, но пока без GUI. Если надо писать приложение под веб, а там GUI и прикладные классы рисуются и управляются пользователем, то вместо того чтобы управление пользователем через браузер внедрять внутрь прикладного класса, его выносят в отдельный класс, который называют контроллером. А модель по прежнему остается независимой от всяких реквестов и урлов принтов и экхо. Модели которые она использовала до внедрения в GUI, она при этом ну ни как не забывает. Если мне надо обратно, как в начале, написать код, не требующий GUI, который просто удалит старые объекты из базы, я отбрасываю контролеры и вьюшки и пишу простой код в моделях, потому что они самодостаточны. всего в 5 строчек. Если я буду полагать, что всегда буду использовать модели через контролеры, или буду иметь возможность использовать без них, но не буду ею пользоваться, тогда зачем вообще писать код в мвц? пропал смысл. писать мвц, чтобы не пользовать преимущества мвц? если это не надо, можно просто писать в прикладных классах PHP: <?php class Prikladnoy{ function doSomething(){ if ($requst->getParam('a')){ //что- то делай } } } очень объекный код. все красиво. а если скажут, надо кли, то делать так PHP: <?php $request->setParam('a'); //сэмулировали запросик, потому что без этого не будет работать а дальше все по обычному $prikladnoy->doSomething(); и все! тоже работает. повторение минимальное, DRY достигрута. чтобы так писать мвц вообще не нужен.
Потому что best practice это low coupling код - когда модель ничего не знает о других моделях. Тогда изменяя что-то в одном месте мы не рискуем сломать десяток других. Представь себе что у меня уже есть интерфейс отсылающий письмо при регистрации. Естественно я воспользуюсь тем же функционалом. Кто-то, где-то врет. Где у тебя в коде независимость? Ты путаешь, модели, модули и утилитные классы/скрипты. И в этом твоя проблема.
Simpliest ну ты даешь. класс Prikladnoy- это анти мвц. я его для примера выдумал, чтобы показать, что если писать как ты, через реквесты и контролеры, то мвц не нужен. да хоть у тебя их десять уже есть, когда у тебя мвц, нет необходимости проводить это через интерфейс. делается все намного проще. берешь напрямую сам отсылающий класс уровня бизнеслогики и отсылаешь письмо им. повторно используется только этот класс, а не весь интерфейс. интерфейс для рассылки писем при регистрации в нормаьлном мвц состоит из контролеров, вьюшек, которыми обернута бизнеслогика моделей. вьюшки, фронт-контролеры, раутеры и вся прочая лабуда для того, чтобы просто отправить письмо не нужны. Вот зачем мвц вообще нужно было выдумать? Какая цель? Бизнеслогика, независимая от пользовательского управления и представления от всех этих контролеров- это основная и единственная цель всей этой замуты. И это сразу становится преимуществом любого мвц приложения. Если ты не можешь использовать модели без контролеров или можешь но не пользуешься, зачем тебе вообще мвц? Пиши как я привел в примере про класс Prikladnoy. Тоже объектно и красиво. не я не путаю. кто-то другой путает, когда говорит, что модель не может использоваться внутри другой модели. По-моему, все что может каким-то образом учавствовать в GUI, может быть реализовано внутри одного класса, как например класс "текстовое поле" в Делфи, или по-парадигме МВЦ через три класса и тогда это модель в торойке МВЦ. Если это реализуется через МВЦ, то класс- это модель, в ней вся бизнеслогика. рисовалка- это вьюшка, а управление в контролере. ровно три класса, не путаю? к примеру, если мне надо отправить письмо человеку в крон скрипте, ума не приложу чем мне может пригодиться вьюшка или управление из GUI. это ты что-то путаешь. Я конечно могу сэмитировать GUI, а потом провести все через контролеры. так поступали до мвц, пока бизнеслогика была перемешана с управлением. если делать все мвц, нет необходимости так извращаться.
Модель - это в первую (да и в последнюю) очередь способ доступа к данным. В принципе, модель может работать с другими моделями, но лишь из одного соображения - целостность данных. Т.е. если две модели связаны так, что изменение/добавление данных в одной модели без внесения соответствующих изменений (или проверок) в другой модели наружит целостность данных - то можно допустить использование моделей внутри других моделей. Но опять же - можно, но не обязательно - это уже на откуп архитектора системы, ибо решений тут много - в некоторых случаях можно пожертвовать целостностью данных оставив нерабочие ссылки (например, удалив город и оставив фирмы со ссылкой на этот город), в некоторых - перенести эту логику на уровень ниже - в базу на основе внешних ключей и тригеров, в некоторых - поместить в модель. Например, в случае с файлами модели допустимо работать с моделью файлов, потому-что иначе будет нарушена целостность (ну или же в каждом контроллере, который использует эту модель придется еще писать и работу с моделью файлов, что черевато как минимум дублированием кода, как максимум - нарушением целостности). Именно по-этому на моделях нельзя написать веб-сервис, как нельзя написать веб-сервис используя лишь СУБД. Модель - это данные, именно так себе их нужно представлять, что бы не ошибиться. Голые данные. Для того, что бы что-то сделать с этими данными - нужен контроллер. Контроллер вполне может быть php скриптом, который дергает модели, почему бы и нет в случае простого консольного скриптика. Другое дело, что контроллер часто содержит одинаковую логику и для cgi и для cli - именно по-этому все же лучше выносить его в отдельные классы. Еще раз - модель - это голые данные, возможно, код по связи этих данных с их источником, возможно, код по конвертации этих данных в другие типы, возможно, код по поддержанию связности и целостности данных. Если модель фирм связана с моделью города, то теоретически допустимо, что модель фирм по связи с городом скажет где-то у себя new City. Практически же это не очень хорошая практика и тут начинают спасать различные датамаперы, которые берут на себя эту функцию. Правда, при этом приходится забыть о new Firm($id) в контроллере и приучиться запрашивать через мапер.
давайте не будем говорить о приемах проектирования моделей. это совсем другая область. мвц не дает никаких советов на эту тему. мвц учит отделять бизнеслогику от пользовательского управления и представления. это и цель и смысл этого паттерна. ну допустим отделили и получили три чистых класса: модель, представление и контроллер. на этом мвц и закончилось. Конец! Дальше уже идет а как связать модели между собой, а как сделать так чтобы изменения в одной не влияли на другую и т.д. Для этого уже используются другие паттерны, не мвц.
В веб-программировании самостоятельной частью системы обычно является модуль. В пределах одного модуля, ИМХО, модели можно свзяывать. Если нужно использовать модели из разных модулей, пускай это делает контроллер.
МВЦ говорит, что модель - это данные, а контроллер - это средство изменения этих данных на основе входных параметров. Если вы в модель запихиваете бизнес-логику по взаимодействию с другими моделями - вы передаете ей функции контроллера. Вот и все. Что нужно уметь, так это провести границу между бизнес-логикой и контролем целостности данных. Четко сделать это не всегда возможно, но никто и не заставляет. И, кстати, Zend_Date не явялется моделью никоим образом, модель это не "все что угодно любой прикладной класс".
Это какой-то новый паттерн? :lol: В веб-программировании самостоятельной частью системы является проект А внутри него нет самостоятельных частей
А это что за паттерн? Проект - это никак не часть системы. Модули в веб-программировании используются очень часто, модуль интегрируется в систему и конечно вне системы не работает. Так вот, чтобы модуль не зависил от других модулей, не надо обращаться из моделей одного модуля к моделям других.
и панислась да ладна. Zend то ничего вроде. объектный пых и всего-то. а мвц его никто не заставляет юзать. Убил. модель МВЦ - это не какой-то спец класс. Нельзя сказать, что это не может являться моделью. Все может стать моделью, если это отображать пользователю через вьюшку и управляется пользователем через контролер. Даже строка $str='qwerty' - это модль для своих вьюшек и контролеров. Даже простой bool $a - это модель для своих вьюшек и контролеров. А Zend_Date и подавно.
vs, могу предположить, что вы пытаетесь оперировать понятиями какого-нибудь фреймворка. Даже могу предположить, что модуль - это что-то вроде набора моделей контроллеров и шаблонов. Проблема в том, что модуль - это такая выдумка для упрощения сленга программистов и ни к MVC ни к всяким best practice отношения не имеет. Да и постулат самодостаточности модулч так же не верен, так как модуль как часть проекта может использовать стандартные модели фреймворка. Например, ту же работу с файлами/картинками. И с другой стороны, даже внутри модуля стоит избегать лишних сцепок между моделями если они не нужны - кто знает, где какая часть потом потребуется.