Любой шаблон для "одного класса на одно действие / страницу"? - PullRequest
3 голосов
/ 21 сентября 2010

MVC - это действительно хороший паттерн, но иногда очень скучно вкладывать все в методы Controller.Контроллер постоянно растет, и требуется время, чтобы избавиться от тысяч строк кода.Некоторые люди настоятельно рекомендуют помещать в Model как можно больше, но я предпочитаю поддерживать чистоту Model (я не помещаю в Model методы, ориентированные на контроллеры).

Идея состоит в том, чтобы поместить действие каждого контроллера в собственный класс...

class Post_Add {}
class Post_Remove {}
class Post_View {}

Весь код, который является общим для всех классов действий, которые мы помещаем в class Post_Parent и передаем его экземпляр в конструктор действий.

Итак, вызов действия будет выглядетькак ...

$parent = new Post_Parent();
$action = new Post_Add($parent);
$action->run();

Итак, что у нас есть?

  • Каждое действие находится в отдельном классе, поэтому мы можем добавить столько приватных методов, переменных, констант, сколько захотим.
  • Весь общий код разделен на родительский класс (Post_Parent) и доступен из классов действий.Это очень хорошо для организации ACL и т. Д. -

Стоит ли жить этой идеей?Существуют ли похожие шаблоны для этого?

Спасибо.

Ответы [ 3 ]

1 голос
/ 21 сентября 2010

Лично я не думаю, что шаблон, который вы описываете, будет хорошо служить вам в долгосрочной перспективе.Если у ваших контроллеров уже есть «тысячи строк кода», у вас есть общая проблема инкапсуляции, и создание класса для каждого действия просто переместит вашу проблему на другой уровень.1003 * тонкий .Вы уже признали это, написав свой пост.Контроллер должен организовать взаимодействие между вашими представлениями и вашей моделью.Модель - это то место, где живет ваша бизнес-логика, поэтому у вашего контроллера должно быть достаточно логики, чтобы обеспечить выполнение соответствующей проверки, правильную бизнес-логику и возврат правильных представлений после завершения обработки бизнес-логики.*

0 голосов
/ 21 сентября 2010

Посмотрите шаблоны Transaction Script и PageController .Сценарий транзакции является самым базовым из шаблонов доменной логики и подходит для небольших приложений.Целью PageController является обработка ввода из вашего пользовательского интерфейса.Если вы хотите, чтобы это была одна команда, ничего страшного.Вы могли бы сделать

class PostAddController implements RequestHandler {
    public function handle($request) {
       $post = filter_input(INPUT_POST, 'post', FILTER_SANITIZE_SPECIAL_CHARS);
       $model = new PostAddTransactionScript;   
       $model->process($post);
       include 'postAddViewScript.php';
    }
}

PostAddTransactionScript затем записал бы $ postData в базу данных или что-то еще, что он должен делать.Упрощенный пример, приведенный выше, будет по-прежнему соответствовать MVC, поскольку он сохраняет логику модели внутри сценария транзакции и обработку ввода внутри уровня представления.

Организуете ли вы логику обработки ввода в один класс Controller или множествоменьшие команды зависит от вас.Группировка обязанностей просто имеет больше смысла, особенно если вам нужно разделить состояние или общие функции между командами.

Что касается вашего примера, я бы лучше использовал шаблон стратегии и имел бы Post_Parentиспользуйте команду вместо команды, использующей Parent, например,

$commander = new PostCommander;
$commander->setStrategy(new PostAddCommand);
$commander->handle($_POST);

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

0 голосов
/ 21 сентября 2010

Я бы посоветовал немного подкрепиться и подумать, почему контроллеры так сильно растут.Может быть, вы могли бы сделать рефакторинг и извлечь некоторые общие компоненты в отдельные модули?Может быть, у вас есть некоторый код в вашей логике, который вместо этого должен быть в вашей модели или представлении?Используете ли вы хорошую систему шаблонов?

Разделение контроллеров на более мелкие части не решит основную проблему, а только сместит ее под коврик.

...