Возможно, мы в пылу дискуссии не до конца поняли друг друга. Насчет того, что прямой вызов контроллера из представления есть зло я полностью согласен. Представление разумеется должно запрашивать нужные ему данные не в сыром виде, а в виде уже сформированной части представления. Я полностью согласен с Вами в том, что попытка запроса сырых данных породит излишние зависимости в системе и, как всегда в таких случаях, родит неповоротливого монстра. Представление ИМХО может делать только одно из двух. Или получать от модели полностью подготовленный набор данных, или запрашивать у системы уже полностью подготовленный фрагмент представления, годный для вставки в нужное место «as is», без какой-либо дополнительной обработки. В случае такого запроса представление абсолютно не должно знать, как и каким образом этот фрагмент будет сформирован. По моему, тут наши позиции полностью совпадают. Согласны?
Согласен, что бывает такое. И это весьма грустно. Может быть я слишком привык пасти своих разработчиков и пресекать такие попытки в корне. У нас обычно интересная или полезная идея выносится на командное обсуждение
По поводу хороша идея, или нет — можно долго ломать копья и устраивать священные войны. На самом деле — каждый архитектор ПО нарабатывает собственные предпочтительные методы построения систем, которые удобны лично ему и соответствуют именно его способу мышления. Каждый из таких подходов имеет свои и сильные стороны, и ограничения. Поэтому, ИМХО, тут спорить просто бесполезно.
Далее. Момент, который Вы, возможно упустили из виду. И в asp.net MVC, и в моем примере, нет прямого обращения к классу контроллера. Есть обращение к системе с просьбой вызвать определенное действие определенного контроллера. И в том, и в другом случае, система вольна произвести замену.
Посмотрите пример внимательнее. Там нет строчки $controller->action. Нет прямого обращения к классу контроллера. Есть обращение $app-> Но, это обращение не к конкретному контроллеру, а к системе в целом. Иными словами, "$app->" примера есть аналог "Html" asp. Жаль, что Вы ведете дискуссию не до конца разобравшись в архитектуре примера.
Верно. Но разве там не указывается имя контроллера, которому принадлежит action? Смотрим строчку: Html.Action(«ActionName», «ControllerName»)
Сравниваем c примером:
$app->handle(«hello»,«say»);
Если назвать метод «handle» примера «Action' и поменять местами имя действия и имя контроллера — в чем будет различие?
Неужели, такие вещи не очевидны?
С замечанием по поводу Razor — соглашусь. А теперь давайте попробуем разобраться с триадой MVC. Полностью согласен с тем, что при вызове partial actions она отрабатывает полностью. И это с моей точки зрения невероятно сильное место ASP. Почему я считаю это сильным местом?
1. Обеспечивается возможность вести сквозную разработку «от представления». Каждое представление само запрашивает у системы нужные данные
2. Обеспечивается возможность легкого внесения изменений в архитектуру и функционал системы, путем замены буквально одной строчки в представлении. Это можно сделать заменив вызов одного partial action на вызов другого.
По сути, в моем примере и была сделана реализация чего-то аналогичного. Кстати, в моем примере также при вызове задействуется вся триада. И контроллер, и модель, которая создается в рамках вызова action, и другое представление. Вся триада на лицо. Разве нет? Более того, если мы говорим о partial action. В примере заложен механизм, позволяющий легко сделать надстройку для пост-обработки данных рендеринга. Функция handle включает захват выходного буфера и записывает его в переменную. Очевидно, что в нормальной реализации системы содержимое этой переменной должно не просто выкидываться функцией echo, как сделано в примере, а проходить пост-обработку через устанавливаемые фильтры. Например для вырезания только нужного участка. Понятно, что иметь в качестве шаблонов непонятные участки html-кода, как сделано в примере, не есть хорошо. Делать такую нарезку — слишком трудоемкая задача. Другое дело, что такие вопросы мне казались абсолютно самоочевидными и не заслуживающими подробного разбора
И тут я с Вами не совсем согласен, увы. По моим понятиям, ни один нормальный разработчик никогда не возьмет код чужого примера в свой проект без изменений. Я, по крайней мере, такие попытки у членов своей команды пресекаю очень жестко. Пример должен максимально четко, ясно и прозрачно показывать архитектурную идею, или технический прием. Так, чтобы разработчик мог легко понять и взять эту идею. Сделав, разумеется, собственную реализацию. И как раз публикаций, которые отвечали бы таким условиям очень мало. Особенно в том, что касается архитектурных решений. Например меня, как потенциального читателя, очень мало интересует как автор назвал класс, или перемекнную. Я все равно назову по своему… Меня интересует как взаимодействуют части системы. Есть ли какой-то простой подход, которого я не знал раньше? Могу ли я за счет материала статьи упростить код и уменьшить его количество? ИМХО это как раз самое важное. Согласны?
Э-э-э. Вызов контроллера (возможно другого, не того, который сейчас проводит рендеринг) из View — как раз распространенная практика. Намного проще, и разумнее, чем писать компоновщик. Такой подход широко используется в рамках системы Razor. Например: stackoverflow.com/questions/21155574/mvc-calling-controller-from-view
Не уверен, что эту систему стоит считать глупой и рекомендую изучить ее архитектуру более пристально… А вот в PHP такой подход использзуется незаслуженно редко.
Далее. Момент, который Вы, возможно упустили из виду. И в asp.net MVC, и в моем примере, нет прямого обращения к классу контроллера. Есть обращение к системе с просьбой вызвать определенное действие определенного контроллера. И в том, и в другом случае, система вольна произвести замену.
Посмотрите пример внимательнее. Там нет строчки $controller->action. Нет прямого обращения к классу контроллера. Есть обращение $app-> Но, это обращение не к конкретному контроллеру, а к системе в целом. Иными словами, "$app->" примера есть аналог "Html" asp. Жаль, что Вы ведете дискуссию не до конца разобравшись в архитектуре примера.
Сравниваем c примером:
$app->handle(«hello»,«say»);
Если назвать метод «handle» примера «Action' и поменять местами имя действия и имя контроллера — в чем будет различие?
Неужели, такие вещи не очевидны?
1. Обеспечивается возможность вести сквозную разработку «от представления». Каждое представление само запрашивает у системы нужные данные
2. Обеспечивается возможность легкого внесения изменений в архитектуру и функционал системы, путем замены буквально одной строчки в представлении. Это можно сделать заменив вызов одного partial action на вызов другого.
По сути, в моем примере и была сделана реализация чего-то аналогичного. Кстати, в моем примере также при вызове задействуется вся триада. И контроллер, и модель, которая создается в рамках вызова action, и другое представление. Вся триада на лицо. Разве нет? Более того, если мы говорим о partial action. В примере заложен механизм, позволяющий легко сделать надстройку для пост-обработки данных рендеринга. Функция handle включает захват выходного буфера и записывает его в переменную. Очевидно, что в нормальной реализации системы содержимое этой переменной должно не просто выкидываться функцией echo, как сделано в примере, а проходить пост-обработку через устанавливаемые фильтры. Например для вырезания только нужного участка. Понятно, что иметь в качестве шаблонов непонятные участки html-кода, как сделано в примере, не есть хорошо. Делать такую нарезку — слишком трудоемкая задача. Другое дело, что такие вопросы мне казались абсолютно самоочевидными и не заслуживающими подробного разбора
stackoverflow.com/questions/21155574/mvc-calling-controller-from-view
Не уверен, что эту систему стоит считать глупой и рекомендую изучить ее архитектуру более пристально… А вот в PHP такой подход использзуется незаслуженно редко.