Yii: Одна большая или несколько маленьких моделей?

Question

[Кирилл Баталин]

Здравствуйте

Подскажите, лучше сделать одну большую модель User (авторизация, регистрация, подтверждение, восстановление пароля) или разделить ее на несколько маленьких?

Вопрос возник, потому что в www.yiiframework.com/doc/guide/1.1/ru/form.model идет разделение (LoginForm отделяют от User, хотя можно было написать все в User и использовать сценарии), а на некоторых других ресурсах (например, www.dbhelp.ru/yii-auth-and-reg-2/page/) все пихают в одну модель

Answer 1

[Сергей Протько]

LoginForm это LoginForm, а User это User. LoginForm может вообще не пересекаться с User (внезапно). Вообще как хотите. Это ж Yii...

Comments

[Кирилл Баталин]

Если разделять модели, то у меня возникает вопрос. Например, если сделать регистрацию, взяв за основу LoginForm с оф.сайта, то будет что-то вроде этого: codepad.org/iI3Xzgun
Но тогда проверка данных будет происходить 2 раза (в RegisterForm и в User). Как этого избежать?

[Сергей Протько]

@kir55rus этого можно избежать отказавшись от AR и использовав компоненты с нормальным разделением ответственности.

[terehinis]

@Fesor Я пологаю что проект @kir55rus пишет не высоконагруженный, а в таком случае AR очень ускоряет разработку. Мы в стартапах используем в основном AR, а если проект добился успеха, то частично проводим модернизацию кода, в том часле используем прямые запросы.

[Сергей Протько]

@terehinis вопрос не в нагрузках. В вопросе явно слышатся нотки интереса как делать "правильно". Так как AR не для правильно а для удобства, можно забить и делать как считаете удобным (в пределах разумного). Да и AR разными бывают, но валидация внутри CActiveRecord явно ошибка.

Answer 2

[terehinis]

Все зависит от того насколько масштабным функционалом будут обладать модели. К примеру если сделаете две модели, и в моделе Users не будет кроме сгенерированного через gii функционала (ну +2 функции к примеру), то разделять особого смысла нет, только скорость потеряете. Если же модель Users будет в себе содержать кучу сложных обработчиков (взаимодействие с другими базами, программный контроль данных и т.д.) то разделить для визуального удобства проще. Все зависит от сложности задачи.

P.S. В большенстве случаев такой функционал объеденяют

Comments

[Кирилл Баталин]

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

Answer 3

[Светлана Окунева]

Проблема решается указанием сценариев - регистрация, авторизация и так далее и соответствующим набором правил валидации для каждого сценария.

Мое личное мнение - не так уж им много там, чтобы разносить на несколько моделей.