MVC и валидация

[stwa]

stwa
А насчет уникальности логина или мыла, это уже в модели User валидируется так?

Нет, все в UserForm
Есть валидатор DbRecordExists, у которого в параметрах надо указать имя таблицы и имя поля, в котором искать совпадения.
Этот валидатор можно использовать с любой моделью, просто здесь мы опускаемся на более низкий уровень абстракции и оперируем с таблицами и полями БД

 

[vanicon]

Есть валидатор DbRecordExists, у которого в параметрах надо указать имя таблицы и имя поля, в котором искать совпадения.
Этот валидатор можно использовать с любой моделью, просто здесь мы опускаемся на более низкий уровень абстракции и оперируем с таблицами и полями БД

Хм, вот как.
Но я бы лучше делегировал эту валидацию классу user.
То есть указать в валидаторе UserForm что правило unique, будет проверятся в статическом методе класса User.
И тогда, будет меньше хлопот если придется поменять бд...

 

[stwa]

Вот как раз, когда поменяете БД, вы получите кучу работы, чтобы внутри каждой модели изменить логику
А в случае с валидатором - это надо сделать только 1 раз, внутри валидатора

 

[vanicon]

Ну если придется менять бд, то в любом случае модель придется изменять, заодно и метод валидации unique изменю...
А валидатор менять и вовсе не придется...

 

[stwa]

Я придерживаюсь другого мнения
Модель предметной области не должна вообще зависить от БД, она вообще не должна знать что такое БД
Погугли насчет паттерна Data Mapper

Вообще сейчас во многих фреймворках делают так:
Модель общается с маппером, а маппер общается с драйвером БД, а уже драйвер генерит запросы на языке СУБД
Обычно такую цепочку выстраивают.
И у валидатора DbRecordExists есть такое свойство, как драйвер БД.
Так что на самом деле при смене БД во фреймворках надо будет сменить только имя драйвера БД в настройках приложения и все должно остаться работать как и раньше
Но это уже не по теме топика

 

[vanicon]

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

 

[fixxxer]

Но если поступать так, то получится что представление станет зависимым от модели

А что, бывают представления, которые не зависят от модели? (Ну не считая вывода абстрактных табличек чего угодно).

Представление знает, что у модели есть email и username - вот, уже зависит.

 

[vanicon]

Да но представление не знает как там происходит валидация данных, и мы можем их менять хоть как..
А в случае передачи тока кода ошибки, надо будет менять еще и в представлениях...
Вот и зависимость...

 

[WMix]

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

представление всегда зависит от модели это и есть визуализация модели

Модель предметной области не должна вообще зависить от БД, она вообще не должна знать что такое БД

а какже CRUD?

fixxxer
идея прикольная, все достаточно прозрачно, хотя и {{ username }} может не всегда существовать, вот только модель, не слишком ли большую роль берет на себя? и модель данных и логика и валидация и ошибки валидации а с этим куча дополнительных методов , дай валидатор, проверь, отфильтруй... (хотя конечно это можно в базовом классе спятать), хм,.. нужно попробывать

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

в моем случае форма состоит из элементов и валидаторов и viewScript для формуляра, на запрос action создает Form, валидирует данные, action запихивает их в model ловит exception, добавляет message рисует форму заного.

 

[vanicon]

представление всегда зависит от модели это и есть визуализация модели

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

 

[stwa]

а какже CRUD?

Модель знает, что в маппере есть 4 метода:
select
insert
update
delete
но не знает как они там реализованы. Этого достаточно
например, с апдейтом код в моделе выглядит так:

 $this->getMapper()->update($data, array('id' => $id))

 

[WMix]

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

тебе казалось! у меня такая картинка перед глазами всегда

 

[stwa]

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

Нет
Контроллер (Controller) для обработки входных данных откуда -нибудь и отправки их моделе (Model),
и наоборот, для обработки данных от модели перед отправкой их в представление (View)

 

[WMix]

Модель знает, что в маппере есть 4 метода

модель то знает, да вот форма если модели не знает будет сложно

 

[stwa]

А у меня всегда такая картинка в голове:

 

[WMix]

твоя картинка ничего не меняет, кроме как показывает что controller контролирует весь процес.
а ну ты это же сам и произнес!

 

[stwa]

не будет ничего сложного.

контроллер знает про модель и про форму, берет данные из модели, заполняет форму и передает ее в представление.
в представлении форма рендерится и показывается на экране (отправляется через json, xml и т.д.)

после получения post-данных (данных из консоли и т.п.) контроллер заполняет форму, вызывает метод валидации у формы и, если, все ок, извлекает данные из формы и передает в модель

модель не знает ничего про форму, все разруливается через контроллер - в этом и есть предназначение контроллера - управлять (контроллировать) потоки

 

[vanicon]

Что то не совсем понимаю, где тут зависимость?
На примере таблиц,
приходит запрос к контроллеру (не важно как и откуда), от отдает нужные данные модели, модель находит соостношение и отдает их контроллеру, тот отдает нужному представлению (гистограмма или еще что нибудь).
Где тут зависимость модели от представления?

 

[fixxxer]

WMix
Не модель берет на себя, а fieldset

Модель просто делает ленивый validate() и если что отказывается продолжать. Ну или может взвести error, скажем, при нарушении unique constraint.

валидация и ошибки валидации а с этим куча дополнительных методов

Ненене! Ничего такого нет. Есть методы validate() и hasErrors(), все остальное гребем во вьюхе (ну, при желании, getError() или field->getError() можно, но не нужно).

Все остальное внутри fieldset-а, и снаружи это трогать не надо.

 

[stwa]

Где тут зависимость модели от представления?

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