Вот поступило задание сделать простое веб-приложение регистрации и авторизации юзеров. Код должен быть ООП, логика отделена от представления (MVC).
Литературу по теме почитал.
Процедурно выполнить здание не составило труда. Начал задумываться об архитектуре на ООП.
Очевидно(мне по кр. мере), что классом тут является собсно User. Методами - добавление юзера в БД (insertUser() к примеру), ну и возможно - авторизации юзера (authUser).
состав insertUser(login, pass1, email)
{
sql-запрос на вставку юзера с такими данными в БД.
....
}
но ведь перед тем как вставить запись, необходимо проверить данные на корректность!
Создавать такой метод в классе User нецелесообразно (имхо), поскольку какой смысл создавать объект, без уверенности что он попадет в БД?
В чем тут должн быть ООП?
Спустя 1 час, 21 секунда (6.01.2010 - 21:49) vagrand написал(а):
Ну в твоем случае это должно быть примерно так:
1. Модель - это класс Users, в котором отображена структура таблицы юзеров. При том, чтобы можно было создать экземпляр этого класса и загрузить в него данные определенного юзера по ID или другим параметрам.
2. Контроллером в данном случае может выступать класс, который возьмет на себя функции, загрузки инфы о юзере в экземпляр класса Users, удаление юзера и обнавление инфы о нем в бд. Так же можно создать отдельные классы (модули) задачей которых будет регистрация и авторизация пользователей.
3. Ну и представление может взять на себя какой-нибудь из существующих шаблонизаторов вроде Smarty или XSLT, либо это могут быть просто отдельные php файлы, в которых будет HTML код с php вставками.
1. Модель - это класс Users, в котором отображена структура таблицы юзеров. При том, чтобы можно было создать экземпляр этого класса и загрузить в него данные определенного юзера по ID или другим параметрам.
2. Контроллером в данном случае может выступать класс, который возьмет на себя функции, загрузки инфы о юзере в экземпляр класса Users, удаление юзера и обнавление инфы о нем в бд. Так же можно создать отдельные классы (модули) задачей которых будет регистрация и авторизация пользователей.
3. Ну и представление может взять на себя какой-нибудь из существующих шаблонизаторов вроде Smarty или XSLT, либо это могут быть просто отдельные php файлы, в которых будет HTML код с php вставками.
Спустя 16 минут, 53 секунды (6.01.2010 - 22:06) tepasaf написал(а):
vagrand
спасибо за развернутый ответ!
В задании нельзя использовать фрэймворков. Задача только реализовать авторизацию и регистрацию.
Видишь ли в чем загвоздка. Класс целесообразно создавать, когда есть много разнотиповых манипуляций с объектом известной структуры.
Но ведь прежде чем заносить запись в БД mysql я должен проверить не пусты ли поля, достаточно длинный ли пароль, есть ли уже в БД юзер такой? Где это делать - в классе отдельным методом? Тогда для проверки валидности записи нужно будет создать объект этого класса, без уверенности что собственно запись будет занесена в БД (юзер зарегистрируется).
Получается эту проверку надо делать в отдельном файле.
Кстати, представление в твоем подходе как реализовать? Как у меня - отдельным файлом?
спасибо за развернутый ответ!
В задании нельзя использовать фрэймворков. Задача только реализовать авторизацию и регистрацию.
Видишь ли в чем загвоздка. Класс целесообразно создавать, когда есть много разнотиповых манипуляций с объектом известной структуры.
Но ведь прежде чем заносить запись в БД mysql я должен проверить не пусты ли поля, достаточно длинный ли пароль, есть ли уже в БД юзер такой? Где это делать - в классе отдельным методом? Тогда для проверки валидности записи нужно будет создать объект этого класса, без уверенности что собственно запись будет занесена в БД (юзер зарегистрируется).
Получается эту проверку надо делать в отдельном файле.
Кстати, представление в твоем подходе как реализовать? Как у меня - отдельным файлом?
Спустя 34 минуты, 7 секунд (6.01.2010 - 22:40) vagrand написал(а):
| Цитата |
| В задании нельзя использовать фрэймворков |
Разве в моем посте есть хоть слово о фреймворках?
| Цитата |
| Но ведь прежде чем заносить запись в БД mysql я должен проверить не пусты ли поля, достаточно длинный ли пароль, есть ли уже в БД юзер такой? Где это делать - в классе отдельным методом? |
Это нужно делать в модулях регистрации и авторизации.
| Цитата |
| Кстати, представление в твоем подходе как реализовать? Как у меня - отдельным файлом? |
Представление я описал в 3-ем пункте
Спустя 4 минуты, 5 секунд (6.01.2010 - 22:44) tepasaf написал(а):
vagrand
Уточни пожалуйста модуль - это что?
Уточни пожалуйста модуль - это что?
Спустя 38 минут, 9 секунд (6.01.2010 - 23:22) vagrand написал(а):
В данном конкретном случае модуль это класс, который управляет поведение страницы (регистрации/авторизации).
Спустя 2 года, 6 месяцев, 7 дней, 15 часов, 55 минут, 59 секунд (14.07.2012 - 14:18) Гость_Влад написал(а):
ИМХО, вам нужно выделять отдельный класс (со статическими методами) который будет заниматься валидацией отдельных параметров(имя,email,пароль и т.д.). Так вы избежите повтора кода валидации в разных классах(тем самым не нарушив правило DRY 
). Что касается регистрации - я бы создал отдельный класс аля Registration для регистрации пользователя. Но это - ИМХО
). Что касается регистрации - я бы создал отдельный класс аля Registration для регистрации пользователя. Но это - ИМХО Спустя 8 часов, 46 минут, 16 секунд (14.07.2012 - 23:05) Guest написал(а):
tepasaf
Если слой бизнес логики впринципе тонкий, а судя по заданию так и есть, не парьтесь с паттерном MVC он подходит больше для приложений с умеренно большим количеством страниц и разнотипным представлением (XSLT, HTML, мобильные телефоны ....)
Взять за основу два входных контроллера совмещённых с FrontController, то есть родительский контроллер будет преобразовывать вызов из URL строки и инициализировать (запускать) команду (метод) зафиксированном в том же URL:
В методах контроллеров для взаимосвязи с БД использовать классы типа ActiveRecord (в этих классах будут методы CRUD, для работы с реляционными таблицами, называемыми шлюзами) перенося в них как бизнес логику (её впринципе здесь совсем немного), так и правила валидации полей, то есть логику самого представления.
Это впоследствии если логика будет расширяться эти модели разойдутся на логическое представление и логическую модель отображения реляционной таблицы в объект.
Если слой бизнес логики впринципе тонкий, а судя по заданию так и есть, не парьтесь с паттерном MVC он подходит больше для приложений с умеренно большим количеством страниц и разнотипным представлением (XSLT, HTML, мобильные телефоны ....)
Взять за основу два входных контроллера совмещённых с FrontController, то есть родительский контроллер будет преобразовывать вызов из URL строки и инициализировать (запускать) команду (метод) зафиксированном в том же URL:
class FrontController {
protected $controller = '' ;
protected $action = ''
;
protected function detectCommandParameter()
{
$this->controller = $_REQUEST['controller'];
$this->action = $_REQUEST['action'];
}
public function run()
{
call_user_function(array($this->controller, $this->action));
}
// Так же контроллер может иметь метод вывода шаблона/страницы
public function renderPage($pathToFileTempalte, array $params)
{
extract($params, EXTR_OVERWRITE);
require($pathToFile);
return true;
}
}
class AuthController extends FrontController {
public function auth()
{
}
}
class RegisterController extends FrontController {
public function register()
{
}
}В методах контроллеров для взаимосвязи с БД использовать классы типа ActiveRecord (в этих классах будут методы CRUD, для работы с реляционными таблицами, называемыми шлюзами) перенося в них как бизнес логику (её впринципе здесь совсем немного), так и правила валидации полей, то есть логику самого представления.
Это впоследствии если логика будет расширяться эти модели разойдутся на логическое представление и логическую модель отображения реляционной таблицы в объект.
Спустя 8 минут, 17 секунд (14.07.2012 - 23:13) Guest написал(а):
Ой сори очепятка, контроллеры Auth и Register не наследую входной контроллер, если бы так было, был бы входной контроллер страниц сервера PageController