Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Несколько вопросов к толковым разработчикам касательно mvc и php

Anna | 31.05.2014 | нет комментариев

Доброго времени суток. Видимо, что для кого-то вопрос нубский, но для меня востребованный.

У нас есть своя наработка, надстройка над биллингом. Первоначально был комплект скриптов, тот, что понемногу заменил и значительно дополнил существовавшую web-морду биллинга. Так вот, теперь вычленяем схожие запросы, разбиваем на классы. Хочу прийти к MVC, но вчитываясь в образцы проектирования Шайки Четырех, статьи на Прогре и в Википедии, вижу, что web-разработчики искажают классическую модель MVC, навешивая на контроллер то, что ему делать не положено. И что самое основное, я иду тем же путем, наступая на те же грабли. Дерзко говоря, теперь я занят тем, что разбиваю функционал системы на контроллеры и модели (фактически для всякого элемента базы данных сделана модель). Не касаясь представлений (применяется смарти, но речь не о темплейтах), объясните дураку, как убрать те косяки, которые я ниже перечислю.

Начну с того, что в процессе разработки я пришел к такой схеме:

index.php — точка входа
class/controller/*Controller.php — Контроллеры
class/model/*Model.php — Модели.

Остальное пока не значимо. Цели, которые ставились, когда шел к этой схеме были примитивны: — Из всех наработанных скриптов убрать итог данных в темплейты;
— Убрать все запросы в БД в отдельные классы (включая проверки на валидность и сообщения в лог изменений);
— Получить массив нужных повсюду данных (тарифные планы, населенные пункты и другое);
— Привести работу с всяким элементом данных к нескольким вариациям:
index, create, update, remove плюс/минус специфичные действия (приблизительно как в yii);
— Авторизация. Уйти от прав доступа ветхого биллинга к правам доступа в новом.

Все это осложняется обратной совместимостью со ветхой веб-мордой, но это решили.

Так вот, то, к чему тяготился, подхожу. Но работая в этом направлении теснее теперь знаю, что переписывать нужно еще раз. чай создавая модель, я представлял себе объект-массив с способами для обновления данных. А в контроллере полагал всю логику. Да, сократить код получилось недурно. Но это вновь говнокод.

Глядите, у меня фактически всякая модель — это класс, реализующий интерфейс ArrayAccess (для работы с объектом класса как с массивом). Но. Для обновления данных сделаны способы. К примеру:

$user=new user(array(‘id’=>$uid));  # создание объекта 
echo $user[‘name’]; # имя пользователя
$user->update_name(‘Vasya’); # обновление имени - проверка, метаморфоза и запись в лог

Теснее тут у меня есть вопросы. Мне доводится при создании объекта user передавать массив. Отчего? Потому что в большинстве случаев мы трудимся с пользователем по id, но пополняет к примеру свой равновесие абонент, указывая логин (ровно как и заходит в индивидуальный кабинет). Как эту строку дозволено оптимизировать? И необходимо ли?

Второе. В классе же модели сейчас у меня есть еще по 2 статических способа (вдалеке не во всех моделях): search($params) и get_all().
search применяется для поиска элементов серди разрешенных. Скажем работники одного филиала не могут видеть абонентов/тарифы иного. search ищет с учетом “прав видимости”. В тоже время get_all нужен при настройке системы. В админке те, кому доступ разрешен, обязаны видеть все элементы данных. Глядите, для того, Дабы обнаружить абонентов, у которых тарифный план с id=39 и населенный пункт Удовольск, доводится формировать такой запрос:

$params=array();
...
$tariff=get_param(‘tariff’, ‘int’, 0);
if ($tariff>0) $params[]=“tariff=$tariff”;

$cities=get_param(‘city’, ‘int_array’, array());
if (!empty($cities)) $params[]=”city IN (”.implode(‘, ’, $cities).”)”;
...
$users=user::search($params);

Если не вдаваться в подробности, что такое get_param, мне не по душе, что я формирую теснее часть запроса тут. По факту же, как мне кажется, контроллер не должен заниматься таким вот обзором. Как типичные разработчики решают аналогичную задачу?

В тоже время возвращаясь к функции get_param, мне кажется она тоже какой-то некрасивый рудимент, но как избавиться от нее пока не представляю. get_param принимает 3 параметра: наименование переменной в запросе (get/post), тип и значение по умолчанию. Собственно, возвращает либо обнаруженное значение, либо значение по умолчанию. Приведу пример контроллера city:

...
	function update(){
		$core=core::getInstance();

		$id=get_param('id', 'int', 0);
...
		$city=new city(array('id'=>$id));
….

		$do=get_param('do', 'string', '');

		if ($do=='update'){
			$name=get_param('name', 'string', $city['name']);
			$phone_code=get_param('phone_code', 'int', $city['phone_code']);

			$city->update_name($name);
			$city->update_phone_code($phone_code);

			header("Location: ?route=city/update&id={$city['id']}");
			exit;
		}

...

Когда данных в форме много, вот этих get_param разрастается такое число, что хочется пойти устроиться разнорабочим на стройку. Вновь-таки, как уйти от такого уродства?

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

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB