В шаблоне MVC модель должна манипулировать только данными, хранящимися в базе данных, и всем поведением, связанным с ней. Итак:
- если у вас есть действие (часть
слой контроллера), который делает много
манипулирования объектом, попробуйте двигаться
такое поведение к методу или группе
методов, поэтому логика обработки данных
остается в слое модели, оставляя
контроллер максимально простой
(он должен манипулировать только отношениями между данными и представлением)
- То же, что и выше, представление должно заботиться только о том, чтобы показывать информацию, а не обрабатывать ее!
Теперь я обычно применяю процесс рефакторинга:
- Найдите код, который кажется связанным
- Попробуйте создать функцию, которая могла бы отображать ее поведение (ищите возможности параметров). Иногда вы будете иметь дело с такими вещами, как Template Method DesignPattern (Здесь вы должны проверить свой код, чтобы убедиться, что он делает то, что должен)
- Заменить исходный код вызовом функции (или в этом случае вызовом экземпляра / статического метода определенного класса) (Проверьте еще раз на функциональность)
Это процесс для любого другого слоя с некоторыми отличиями:
- в слое Controller вам нужно будет использовать Компоненты и Действия вместо статических методов / методов экземпляра.
- в слое представления вы должны создать партиалы, слоты и шаблоны для их рефакторинга.
Реальный пример: у вас есть запрос, который проверит существование конкретной записи с заданным значением поля 'name', и вы хотите использовать ее повсюду, затем:
- проверьте, какой тип информации вы обрабатываете. В данном случае это PeerStructure, которая должна каким-то образом фильтровать результаты таблицы в зависимости от значения таблицы. Если вы проверите, я сказал: «Peer ...», «Table» дважды, поэтому я думаю о создании статического метода в классе Peer, который обрабатывает значения, которые я хочу отфильтровать, скажем, ApplicationUser.
- Теперь, когда я знаю, что собираюсь построить, проверьте параметры, которые могут присутствовать или не присутствовать. В этом случае «имя» является возможным параметром (это также может быть критерием). Также вы должны подумать о том, какие значения вы собираетесь вернуть. И поскольку мы говорим о статическом методе в одноранговом классе, я предполагаю, что есть два возможных значения: Criteria или ResultSet (под этим я подразумеваю набор результатов, а не структуру).
Наконец, создайте статический метод.
публичная статическая функция countUsername ($ username)
{
$ c = новые критерии ();
$ C-> добавить (ApplicationUserPeer :: NAME, $ имя, Criteria :: EQUAL);
return ApplicationUserPeer :: doCount ($ c);
}
Теперь, когда у вас есть функция, пришло время заменить старую логику, чтобы использовать новый метод. Допустим, вам нужно проверить, доступно ли имя для использования новым пользователем, который пытается зарегистрироваться. В некоторых действиях у вас должен быть фрагмент кода, который выглядит следующим образом:
public function executeCreateUser(sfWebRequest $request)
{
[...]
$c = new Criteria();
$c->add(ApplicationUserPeer::NAME,$request->getParameter('username'),Criteria::EQUAL);
;
if(ApplicationUserPeer::doCount($c) == 0)
{
//Then do some stuff that saves
}
[...]
}
После использования вашей функции ваш код может выглядеть следующим образом:
public function executeCreateUser(sfWebRequest $request)
{
[...]
if(ApplicationUserPeer::countUsername($request->getParameter('username')) == 0)
{
//Then do some stuff that saves
}
[...]
}
Так что это процесс в действии, помните, что вы всегда можете рефакторинг даже больше. Например, если вы думаете о параметре, который я выбрал для этого примера, и о его связи с функциональностью, вы также можете добавить «CriteriaMethodParameter», значения по умолчанию которого равны, но если вам теперь нужны все имена пользователей с буквой A, вы можете установить CriteriaMethodParameter для параметра Like, в любое время, просто изменив параметр.