Обязанности сущностей

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

вот и призываю народу объедениться, собрать весь свой личный опыт и описать каким должна быть система работы с юзерами и как её будет лучше оформить в виде программного кода.

(Отредактировано автором: 04 Июня, 2012 - 01:21:14)

Вот когда поймешь это тогда и поймешь что книжная теория тут малополезна.


Так Макконел уже собрал. Сильно помогло?

(Отредактировано автором: 04 Июня, 2012 - 01:28:34)

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

эх ) несговорчивые нынче люди ;) и грубые какие-то...

(Отредактировано автором: 04 Июня, 2012 - 01:33:52)

Я вот эту книгу не читал, хотя и скачал но и без её замысловатых идей знаю : caballer'ыч прав, имхо!
Класс User это сущность.
Методы регистрации, авторизации должны быть внутри этой сущности. Информацию о пользователе можно хранить в приватном свойстве объекта.
(Добавление)
ООП не должно плодить классы ради классов!!

Я стремлюсь к простоте интерфейса и не хочу загромождать класс интерфейсом, который будет использован всего 1 раз при регистрации. Про авторизацию молчу, там ей и место но вот на счет регистрации... Если разбить приложение на подсистемы, то вырисовывается пакет Account System. В нем класс Account (user)...

О! А стоит сделать абстрактный базовый класс и от него наследовать Guest, User, Admin? А в базовом классе сделать статическими методы авторизации и регистрации? Есть ли в этом смысл?

Bio man, нету. Роли уместней всего хранить не отдельным классом, пусть даже "наследником" чего-то там, а в битовых масках, это тоже имхо....

Ну да лучше сгородить целый класс одним методом для одного раза. Большинство фреймворков и CMS потому и сложны для понимания что разбиты на стопицот малополезных подсистем.
Как показывает практика (и об этом пишет Фаулер) писать код "на всякий случай" - глупо потому что этот "случай" в большинстве случаев не наступает. и соответственно код валяется без дела.
Впрочем иногда поступают следующим образом - создают хелперный класс куда переносят все невписыывающиеся с сущности функции. Класс сам по себе смысла не имеет как обьект (тем более функции как правило там статические) но закрывает все нестыковки.


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

(Отредактировано автором: 04 Июня, 2012 - 11:01:16)

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

нет
Завтра тебе понадобятся модераторы, и что? ты будешь еще один класс наследовать?

-----
Чем больше узнаю, тем больше я не знаю.

DelphinPRO
Да понял я, что не лучшая идея и разруливать это с помощью ACL нужно.

начал по маленьку формулировать мысли на тему работы с юзерами, пока получается вот что http://smart-core[dot]org/wiki/Users

если у кого есть мысли каким функционалом должен еще обладать комплект компонентов по работе с юзерами - пишите!

UML диаграмки бы не помешали

до описания UML надо на словах сформулировать какими требованиями и возможностями будет обладать подсистема работы с юзерами в целом... да и в этом случае важными будет только интерфейсы.