контролеров и экшенов для HTTP тоже не существует. Это архитектура поверх HTTP. .NET WebForms — класический пример с событиями.
Собственно — это пример компонентного подхода, гораздо более естественного для веба (для разработчиков веба) чем MVC.
MVP придумали позже. Когда увидели что MVC не всегда лепится куда попало.
это как в квантовой физике — когда ученые не могут пояснить поведение частицы — они придумывают новую. И этих мюонов, мезонов и прочих уже больше чем ученых-физиков.
Слои в MVC живут не дальше и не ближе.
Они живут независимо — гляньте картинку в википедии. Между слоями стрелочки в обе стороны. А у вас контроллер по неведомой причине посередине оказывается.
Представление обычно обращается к модели напрямую потому что только представление знает какие данные в каком виде ему нужны для рендеринга. Контроллер только дает команду — предьяви такой то контент. Например юзера васю пупкина.
А все потроха васи пупкина представление запрашивает у моели — нуджно только фамилию берет фамилию — надо фотку — тогда и фотку.
А еще модель может дернуть контроллер — у меня сменились данные (каким то стороним воздействием — что то отредактировали напрямую) — а ну-ка обнови представление актуальными данными…
Это если по уму — но поскольку MVC в вебе как я уже написал -полная чушь то тут конечно можно что угодно лепить.
да дело не в истоках а в том где MVC паттерн применялся естественым образом. Четким, однозначным и понятным как полагается паттернам. Иначе это не паттерны.
уверен что есть паттерны, описывающие сервисные архитектуры. и это не MVC паттерн.
Если брать MVC паттерн как идею отделения мух от котлет то конешно туда много чего подходит.
А вот когда доходит до конкретной реализации в стиле а-ля Zend. начинаются танцы с бубном, как у ТС.
И не только — обратите внимание на форумы сколько там дискусий — что должно относится к модели, кто должен передавать данные представлению контроллер или контроллер высчивает представление а представление само вычитывает модель.
Странно для вещи претендующей на названия паттерна — ведь смысл паттернов именно четкое описание архитектуры.
обработчик события — всегда связан с событием. Это не просто функция. И параметры ему не нужны, кроме разве что ссылку на сендера.
А экшен можно и строки адреса ввода вызвать — это просто URL.
с таким же успехом представлением можно назвать пакет байтов, возвращаемых драйвером сервера БД.
Я понимаю при желании термины MVC можно прикрутить к чему угодно. Только в этом случае не очевидно где что. и шо это за паттерн в таком случае?
он абстрактный по назначению. Не проектируется екшен для связи с кнопкой.
У вас еще нет дизайна и вы не знаете какая там кнопка — но у вас уже может быть екшен — для выполнения какой то операции.
там где нет людей там как минимум нет представления.
В таких случаях используется что то типа сервисно-ориентированной архитектуры. И шо там вообще делать MVC?
класический MVC как он был придуман — задолго до веба. И именно так он всегда и реализовывался в приложениях. В пятой визуал студио даже шаблон проекта был такой. Меню — контроллер, модель — документ. А в окне где рендерится документ — соответственно представление.
Word — как пример.
По-хорошему, модель в MVC не должна быть моделью из ORM.
по хорошему, если исходить из идеи MVC другой модели и не бывает, потому как модель — это модель бизнес-данных, включающая, к слову, и бизнес-логику.
Стопицот файлов в папке model это не модели, если по уму, а DTO. Даже если класс по совместительству является бизнес сущностью — User к примеру.
И контроллер кстати должен быть один. Потому контроллером скорее является роутер в точке входа где нибудь в index.php, чем опять же стопицот файлов в папке Controllers.
Множество раз я пытался писать, следуя патерну, но результат всегда доводил меня до безумия.
Ожидаемо. Паттерн MVC в вебе, как я уже писал тут в своей публикации — как на корове седло. HMVC и прочие изощрения только доказывают несостоятельность MVC паттерна (имеется ввиду паттерн в вебе а не вообще).
Нет ничего естественнее для веба чем компонентный подход. Хотя бы потому что пользователь видит интерфейс и взаимодействует с элементами интерфейса а не с контроллерами. Если человек нажал кнопку то должно отработать событие связанное с кнопкой а не абстрактный экшен.
Пользы от делфи тут не намного больше. Java по кравней мере кросплатформенная и к ей проще прикрутить какой нибудь скриптовый язык в виде DSL.
Но это по любому не спасает «отца русской демократии»
Никакой бухгалтер не станет осваивать язык програмирования. Последняя версия 1С где я видел чтобы бухгалтер редактировал что то была 1С 2.0.
Попытка повторения 1С на делфи или яве заранее обречена на провал. Плюсов 1с не достигаем зато добавляем минусов в виде приложения которое еще и перекомпиливать приходится. То есть если для 1С требовался приходящий програмист то здесь придется держать штатного. Но в таком случае зачем построитель форм? Достаточнго было бы какого нибудь декларативного дизайна.
Впрочем, как раз готовлю статью про то как следует писать приложения-альтернативы 1С.
.
Собственно — это пример компонентного подхода, гораздо более естественного для веба (для разработчиков веба) чем MVC.
Вы можете применить паттерн фасад или компоновщик где угодно — лишь бы данные были?
это как в квантовой физике — когда ученые не могут пояснить поведение частицы — они придумывают новую. И этих мюонов, мезонов и прочих уже больше чем ученых-физиков.
Они живут независимо — гляньте картинку в википедии. Между слоями стрелочки в обе стороны. А у вас контроллер по неведомой причине посередине оказывается.
Представление обычно обращается к модели напрямую потому что только представление знает какие данные в каком виде ему нужны для рендеринга. Контроллер только дает команду — предьяви такой то контент. Например юзера васю пупкина.
А все потроха васи пупкина представление запрашивает у моели — нуджно только фамилию берет фамилию — надо фотку — тогда и фотку.
А еще модель может дернуть контроллер — у меня сменились данные (каким то стороним воздействием — что то отредактировали напрямую) — а ну-ка обнови представление актуальными данными…
Это если по уму — но поскольку MVC в вебе как я уже написал -полная чушь то тут конечно можно что угодно лепить.
Если брать MVC паттерн как идею отделения мух от котлет то конешно туда много чего подходит.
А вот когда доходит до конкретной реализации в стиле а-ля Zend. начинаются танцы с бубном, как у ТС.
И не только — обратите внимание на форумы сколько там дискусий — что должно относится к модели, кто должен передавать данные представлению контроллер или контроллер высчивает представление а представление само вычитывает модель.
Странно для вещи претендующей на названия паттерна — ведь смысл паттернов именно четкое описание архитектуры.
А экшен можно и строки адреса ввода вызвать — это просто URL.
Я понимаю при желании термины MVC можно прикрутить к чему угодно. Только в этом случае не очевидно где что. и шо это за паттерн в таком случае?
Обработчик события — всегда обработчик КОНКРЕТНОГО события — например нажатия на эту кнопку. Даже если вы его поцепили еще и на линк.
У вас еще нет дизайна и вы не знаете какая там кнопка — но у вас уже может быть екшен — для выполнения какой то операции.
В таких случаях используется что то типа сервисно-ориентированной архитектуры. И шо там вообще делать MVC?
Word — как пример.
по хорошему, если исходить из идеи MVC другой модели и не бывает, потому как модель — это модель бизнес-данных, включающая, к слову, и бизнес-логику.
Стопицот файлов в папке model это не модели, если по уму, а DTO. Даже если класс по совместительству является бизнес сущностью — User к примеру.
И контроллер кстати должен быть один. Потому контроллером скорее является роутер в точке входа где нибудь в index.php, чем опять же стопицот файлов в папке Controllers.
а может все таки персистентный хранилищем — ну там я знаю… сервером Бд например.
Ожидаемо. Паттерн MVC в вебе, как я уже писал тут в своей публикации — как на корове седло. HMVC и прочие изощрения только доказывают несостоятельность MVC паттерна (имеется ввиду паттерн в вебе а не вообще).
Нет ничего естественнее для веба чем компонентный подход. Хотя бы потому что пользователь видит интерфейс и взаимодействует с элементами интерфейса а не с контроллерами. Если человек нажал кнопку то должно отработать событие связанное с кнопкой а не абстрактный экшен.
Но это по любому не спасает «отца русской демократии»
Попытка повторения 1С на делфи или яве заранее обречена на провал. Плюсов 1с не достигаем зато добавляем минусов в виде приложения которое еще и перекомпиливать приходится. То есть если для 1С требовался приходящий програмист то здесь придется держать штатного. Но в таком случае зачем построитель форм? Достаточнго было бы какого нибудь декларативного дизайна.
Впрочем, как раз готовлю статью про то как следует писать приложения-альтернативы 1С.
.
у мускула как раз нет оконных функций