- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
/**
* Обновление информации о пользователе
*
* @param integer $user_id
* @param array $data
* @return Zend_Db_Statement_Pdo
*/
public function updateProfile($user_id, $data)
{
// TODO: сделать человеческую валидацию
$params = $keys = array();
if ($data['login'] !== NULL) {
$keys[] = 'u_login = ?';
$params[] = $data['login'];
}
if (Zend_Validate::is($data['email'], 'EmailAddress')) {
$keys[] = 'u_email = ?';
$params[] = $data['email'];
}
if ($data['sname'] !== NULL) {
$keys[] = 'u_sname = ?';
$params[] = $data['sname'];
}
if ($data['name'] !== NULL) {
$keys[] = 'u_name = ?';
$params[] = $data['name'];
}
if ($data['fname'] !== NULL) {
$keys[] = 'u_fname = ?';
$params[] = $data['fname'];
}
if ($data['birthdate'] !== NULL) {
$keys[] = 'u_birthdate = ?';
$params[] = $data['birthdate'];
} else {
$keys[] = 'u_birthdate = NULL';
}
if ($data['city'] !== NULL) {
$keys[] = 'u_c_id = ?';
$params[] = (int) $data['city'];
}
if ($data['info'] !== NULL) {
$keys[] = 'u_info = ?';
$params[] = $data['info'];
}
if ($data['sign'] !== NULL) {
$keys[] = 'u_sign = ?';
$params[] = $data['sign'];
}
if ($data['sex'] === 'M' OR $data['sex'] === 'F') {
$keys[] = 'u_sex = ?';
$params[] = $data['sex'];
}
if ($data['subscribe'] === 'on' AND ($data['subtype'] === 'T' OR $data['subtype'] === 'H')) {
$keys[] = 'u_subscribed = ?';
$params[] = $data['subtype'] === 'T' ? 1 : 2;
} else {
$keys[] = 'u_subscribed = ?';
$params[] = 0;
}
$sql = 'UPDATE users SET ' . implode(', ', $keys) . ' WHERE u_id = ' . (int) $user_id;
$query = $this->db->query($sql, $params);
$this->clearUserCache($user_id);
return $query;
}
Follow us!
//TODO: Выучить ООП, перестать юзать хеши хешей
//TODO: Научится пользоваться константами
//TODO: Научится отделять логику от DAO
//TODO: Изучить prepared statemenets
//TODO: Нанять человеческого программиста
не нанимать парней с некоторых стран Азии
у нас это называется "массив массивович"
а Вы реально думаете что вместо объектов или структур лучше исползовать ассоциативные массивы?
2) Если опечататься, и вместо "sex" написать "six" (кстати пол по-английски будет "gender"), то у объекта PHP ругнется, что метода "getSix" нет. А так не ругется.
Вообще честно говоря я так вот не готов взять, и одним постом объяснить приимущества объектно-ориентированого подхода. Тут нужно читать серию лекций.
Вы тоже не понимаете зачем применять ООП?
Если мы организовываем только структуру данных (как вот struct в С или record в Pascal) и нам не нужны действия с ними, то за ДРУГИМИ некоторыми исключениями подходы равнозначны.
Но если вдруг нам нужны и действия, то, конечно, лучше связать их с данными в традициях ООП
Причем он не только в DAO, но и в бизнес-логике (хотя они тут и перемешанны).
Вы в джаве тоже Map используете вместо DTO? А в .NETе -- Dictionary?
в джаве противоположная ситуация: предпочтительнее создать POJO сущность, поля и аксессоры, а Картами пользоваться только если требуется динамичность
phpstorm даже геттеры и сеттеры умеет генерить.
Знаю-знаю, необходимость его подключения, правда?
Кроме того классы можно генерить по структуре базы (так много кто делает в языках, отличных от PHP)
А кроме того, можно воспользоваться ORM
Потому что обращение к свойству можно переопределить (__get)
с помощью __get -- мы получим их практически с аксессорами
2. Вы не внимательны - если в хэше не будет ключа sex, то он не пройдет по условию (хотя, по-хорошему там следовало бы добавить isset()) и не добавиться в запрос.
Объектно-ориентированный подход - это, конечно-же хорошо, но не стоит его применять полностью везде, как уже сказал Lure Of Chaos.
Вы наверное имеете ввиду ассоциативный массив? Так вот он сделан для динамически изменяющихся данных.
Т.е получается, что в случае с объектом мы реализовали совсем простой и функциональный интерфейс. А представьте теперь, что у пользователя есть какой-то счёт/аккаунт в торговой системе, и нужно вывести его баланс, а для этого нужно приконнектиться к удалённой торговой системе и спросить этот самый баланс. Какой интерфейс вы будете использовать, уже определились?
Во всех приличных фреймворках за валидацию отвечает ORM - это централизованно, удобно и "правильно", как я поясню ниже. Один из вариантов:
Честно говоря смотря на код, не вижу почему нельзя было бы сделать как в примере выше. Данные на входе - это данные пользователя. В каком виде они должны храниться и что из себя представлять (структура, формат, допустимые значения) должен знать сам объект класса User, а не какой-то там хитрый кастомный валидатор в виде массива.
вернет 0