ForJest
- свежая кровь
Ямерт
Угу. Я уже начитался. То что ты сказал SuperAction назвали FrontController.
Согласен. Action зависит напрямую от запроса, данных которые пришли. И лишь controller может решить что будет делаться, поэтому оно типа включается внутрь.
Но. Есть один момент. Данные изменяются до того, как начинается вывод. Всегда это так происходит.
Ну и получается что на контроллер (Я говорю о PageController) возложены роли
1. решить что делать
2. сделать
3. устанровить состояние модели
4. выбрать View
5. передать управление View.
----------------------------------------
Если я всё правильно понимаю то причина, по которой пункты 2 и 4 находятся в "одной коробке" это п.1.
Окей - получается контроллер должен владеть информацией о том, что делать для того чтобы правильно выбрать View и привести модель в нужное состояние.
Если мы избавим его он проблемы выбора - тогда у него останется один View. И автоматически исчезнет необходимость в выполнении Actions именно конкретным PageController - это может сделать FrontController перед вызовом PageController.
т.е. цепочка
1. Решить что делать - найти нужный PageController
2. Выполнить Actions для этого случая
3. Передать управление PageController.
Но PageController лучше всех знает что ему нужно делать получается, поэтому лучше Actions отдать ему
....
------------------------------------
В общем я понял. При MVC подходе приложение обретает древовидную структуру.
В узлах стоят FrontControllers. А листьями идут PageController.
Т.е. если какой-то PageController стал слишком сложным, его нужно разбить на несколько "листьев" и преобразовать его в узел, который будет управлять вновь созданными листьями. Так можно гибко наращивать структуру приложения, что есть гуд.
Опять же это создаёт оптимальное дерево для передачи событий/управления.
Угу. Я уже начитался. То что ты сказал SuperAction назвали FrontController.
Согласен. Action зависит напрямую от запроса, данных которые пришли. И лишь controller может решить что будет делаться, поэтому оно типа включается внутрь.
Но. Есть один момент. Данные изменяются до того, как начинается вывод. Всегда это так происходит.
Ну и получается что на контроллер (Я говорю о PageController) возложены роли
1. решить что делать
2. сделать
3. устанровить состояние модели
4. выбрать View
5. передать управление View.
----------------------------------------
Если я всё правильно понимаю то причина, по которой пункты 2 и 4 находятся в "одной коробке" это п.1.
Окей - получается контроллер должен владеть информацией о том, что делать для того чтобы правильно выбрать View и привести модель в нужное состояние.
Если мы избавим его он проблемы выбора - тогда у него останется один View. И автоматически исчезнет необходимость в выполнении Actions именно конкретным PageController - это может сделать FrontController перед вызовом PageController.
т.е. цепочка
1. Решить что делать - найти нужный PageController
2. Выполнить Actions для этого случая
3. Передать управление PageController.
Но PageController лучше всех знает что ему нужно делать получается, поэтому лучше Actions отдать ему
....------------------------------------
В общем я понял. При MVC подходе приложение обретает древовидную структуру.
В узлах стоят FrontControllers. А листьями идут PageController.
Т.е. если какой-то PageController стал слишком сложным, его нужно разбить на несколько "листьев" и преобразовать его в узел, который будет управлять вновь созданными листьями. Так можно гибко наращивать структуру приложения, что есть гуд.
Опять же это создаёт оптимальное дерево для передачи событий/управления.
