Comments 39
В тоже время, для меня остался открытым вопрос, насколько можно применить концепцию MVC при разработке обычных приложений (например, для Windows)Паттерну MVC несколько десятилетей, и он пришел в web из «десктопного» мира.
Вопрос не в том «возможно или нет», вопрос в том насколько целесообразно применять концепцию MVC в современном программирования. В 1979 году применялось в основном однопоточное линейное программирование (где концепцию MVC применить было оптимально), сегодня же популярны многопоточные приложения и применение концепции MVC, мне кажется, здесь уже не так оптимально. Опять таки, по состоянию на сегодняшний день у меня есть один Web проект построений с использованием MVC, думаю, в скором времени, опробую концепцию и на Windows приложении.
Ну так все зависит от потребностей: MVC не претендует на роль единственноверного паттерна.
Приложения то многопоточные, но вы забываете про GUI поток, который является единственным. MVC (MVP, MVVM) как раз и обеспечивает перенаправление однопоточного GUI в многопоточные обработчики. При должной сноровке количество написанного кода при таком подходе сокращается в разы.
MVC кстати многие считают шаблонным патерном для WPF, уверяя что он более удобен чем MVVM.
MVC кстати многие считают шаблонным патерном для WPF, уверяя что он более удобен чем MVVM.
Как-то вы все не до конца поняли по моему, вам стоит посмотреть на реализацию в различных готовых системах.
1. Вы пишите Controller -> Model -> View — это в корни не верно, модель никакого отношения к представлениям вообще не имеет — там только логика и данные. Контроллер получает запрос, что-то с ним делает, на основании его подключает или не подключает модели, получает или не получает данные и далее может отдать их сразу или вызвать рендер представления — это в упрощенном виде, т.к. здесь еще могут быть ACL или еще неке действия связанные с другими частями приложения
2. Вы упускаете тот факт, что MVC в чистом виде сейчас редко где встретишь. Почти везде есть помощники / поведения / блоки и т.д., а так же все это подкреплено всякими реестрами / репозитариями / событиями и т.д…
3. На модули делить очень даже просто — MVC будет внутри модуля и к слову сказать — совершенно не обязательно, чтобы у модуля к примеру был свой контроллер, он вполне себе может существовать и без него, или без модели
4. На счет расходов ресурсов — подозреваю что если использовать mvc это будет кушать больше ресурсов чем тот подход, который вы описывали, но не на так много как вы описываете. MVC это ООП — а в ООП в основном оперируют объектами, а они в свою очередь передаются по ссылке — поэтому никаких дополнительных расходов ресурсов особо не происходит. Но при грамотном построении архитектуры, когда проект разрастается, его намного проще поддерживать и развивать
как-то так в кратце.
1. Вы пишите Controller -> Model -> View — это в корни не верно, модель никакого отношения к представлениям вообще не имеет — там только логика и данные. Контроллер получает запрос, что-то с ним делает, на основании его подключает или не подключает модели, получает или не получает данные и далее может отдать их сразу или вызвать рендер представления — это в упрощенном виде, т.к. здесь еще могут быть ACL или еще неке действия связанные с другими частями приложения
2. Вы упускаете тот факт, что MVC в чистом виде сейчас редко где встретишь. Почти везде есть помощники / поведения / блоки и т.д., а так же все это подкреплено всякими реестрами / репозитариями / событиями и т.д…
3. На модули делить очень даже просто — MVC будет внутри модуля и к слову сказать — совершенно не обязательно, чтобы у модуля к примеру был свой контроллер, он вполне себе может существовать и без него, или без модели
4. На счет расходов ресурсов — подозреваю что если использовать mvc это будет кушать больше ресурсов чем тот подход, который вы описывали, но не на так много как вы описываете. MVC это ООП — а в ООП в основном оперируют объектами, а они в свою очередь передаются по ссылке — поэтому никаких дополнительных расходов ресурсов особо не происходит. Но при грамотном построении архитектуры, когда проект разрастается, его намного проще поддерживать и развивать
как-то так в кратце.
1. Controller -> Model -> View — это я написал упрощенный вариант последовательности, конечно, если вдаваться в подробности, то цепочка будет иметь вид CMCVC.
«Контроллер получает запрос, что-то с ним делает, на основании его подключает или не подключает модели, получает или не получает данные и далее может отдать их сразу или вызвать рендер представления» — могу сделать вывод, что у Вас часть логики работы приложения лежит в контроллере (исходя из того, что у Вас контроллер получает или не получает данные), а википедия говорит, что это наиболее распространенная ошибка.
2. Я написал исключительно свое мнение о применении MVC в своем проекте, где использовал MVC в чистом виде. Я ни слова не сказал как его обычно применяют при реализации «среднестатистических проектов». К чему это утверждение я не понимаю.
3. Я пишу о функциональных модулях программы. Функциональный модуль — это некий логически завешенная часть программы, реализующая какую нибудь самостоятельную функцию. Например, функциональный модуль отвечающий за комментарии пользователей. Такой модуль включает в себя элементы контроллера (загрузка параметров для комментариев), элементы модели (загрузка данных из СУБД и применение параметров определенных контролером) и элементы отображения (механизм визуализации комментариев).
Учитывая Вашу ошибку из 1-го пункта (где часть логики работы программы находится в контроллере), я согласен, что не во всех случаях необходимо подключать модель или отображение (не всегда есть необходимость обращение к данным или визуализации результатов). Но при правильно организации, программа без модели будет бессмысленна.
4. «но не на так много как вы описываете» я и не пишу, что на много больше, я пишу что больше.
Мне не понятно как выбор подхода (функциональный или объектно ориентированный) влияет на объем памяти, необходимый для хранения данных? Например, одним из параметров программы (в моем проекте) является URL, как известно это обычная строка. В MVC контроллер разбирает URL и распределяет его части в переменные (URL «server/ru/blog/» загружается в 3 переменные/свойства $server, $language и $category). Далее модель будет оперировать исключительно этими переменными.
В модульном подходе, модуль сам обращается к URL строке и находит нужный ему параметр, таки образом неиспользуемые параметры не загружаются вообще.
Может пример с URL я подобрал не очень хороший (POST параметры, были бы более наглядными), но суть я надеюсь Вы уловили.
«Контроллер получает запрос, что-то с ним делает, на основании его подключает или не подключает модели, получает или не получает данные и далее может отдать их сразу или вызвать рендер представления» — могу сделать вывод, что у Вас часть логики работы приложения лежит в контроллере (исходя из того, что у Вас контроллер получает или не получает данные), а википедия говорит, что это наиболее распространенная ошибка.
2. Я написал исключительно свое мнение о применении MVC в своем проекте, где использовал MVC в чистом виде. Я ни слова не сказал как его обычно применяют при реализации «среднестатистических проектов». К чему это утверждение я не понимаю.
3. Я пишу о функциональных модулях программы. Функциональный модуль — это некий логически завешенная часть программы, реализующая какую нибудь самостоятельную функцию. Например, функциональный модуль отвечающий за комментарии пользователей. Такой модуль включает в себя элементы контроллера (загрузка параметров для комментариев), элементы модели (загрузка данных из СУБД и применение параметров определенных контролером) и элементы отображения (механизм визуализации комментариев).
Учитывая Вашу ошибку из 1-го пункта (где часть логики работы программы находится в контроллере), я согласен, что не во всех случаях необходимо подключать модель или отображение (не всегда есть необходимость обращение к данным или визуализации результатов). Но при правильно организации, программа без модели будет бессмысленна.
4. «но не на так много как вы описываете» я и не пишу, что на много больше, я пишу что больше.
Мне не понятно как выбор подхода (функциональный или объектно ориентированный) влияет на объем памяти, необходимый для хранения данных? Например, одним из параметров программы (в моем проекте) является URL, как известно это обычная строка. В MVC контроллер разбирает URL и распределяет его части в переменные (URL «server/ru/blog/» загружается в 3 переменные/свойства $server, $language и $category). Далее модель будет оперировать исключительно этими переменными.
В модульном подходе, модуль сам обращается к URL строке и находит нужный ему параметр, таки образом неиспользуемые параметры не загружаются вообще.
Может пример с URL я подобрал не очень хороший (POST параметры, были бы более наглядными), но суть я надеюсь Вы уловили.
1. Не правильно предполагаете — просто некй экшен может просто отдавать статику, а значит ему не надо дергать модель. Или же наоборот — он отвечает на некий ajax запрос, или режим работы апи — тогда он не рендериит ничего, а отдает данные например в виде json. так же в контроллере вполне может происходить некая предвариительная проверка / валидация форм…
2. Это было относительно недостатков раздела 1, где описано кто что делает и как все плохо из-за этого. Просто тут имхо на не совсем мелком проекте хотябы без хелперов никуда, иначе появится дублирование кода или базовые классы будут сильно обрастать функционалом — имеются ввиду базовый контроллер / модель / въюха
3. Никакой ошибки там нет. Без модели конечно сложно пример придумать в чистом MVC, но думаю тоже найдется если подумать.
3.1. Пример без вьюшек уже приводил — когда аджакс запрос, ожидающий данные в json или в вииде строки, любой api почти всегда тоже будет без вьюшек.
3.2. Без контроллера — тоже без проблем, есть модель которая тянет данные со стороннего сервиса через апи, эти данные нужны лишь в отдельном блоке сбоку, но никогда не открываются как отдельная страница.
3.3. Касательно функциональных модулей — я пишу о том же, абсолютно о том же.
4. Вы пишите что больше и этого уже достаточно. Если говорить об урл, то при текущих серверах это пренебрежимо мало и не стоит это относить к недостаткам. Я же писал о том как было ранее — получили данные из БД, они как правило в виде обычного массива, далее оперируют этим массивом. Если передавать массив и он большой, то по умолчанию он будет копироваться и да, будет кушать память. Сейчас же это скорее будет некая коллекция и передаваться будет в виде объекта, а он по умолчанию не будет копироваться и кушать память
4.1. В MVC контроллер не должен разбирать урл. Урл должен разбираться до контроллера, либо как-то напрямую, но лучше в неком классе Request и уже на основе этого урла разобранного как-раз и будет подключаться и вызываться некий метод некого контроллера
2. Это было относительно недостатков раздела 1, где описано кто что делает и как все плохо из-за этого. Просто тут имхо на не совсем мелком проекте хотябы без хелперов никуда, иначе появится дублирование кода или базовые классы будут сильно обрастать функционалом — имеются ввиду базовый контроллер / модель / въюха
3. Никакой ошибки там нет. Без модели конечно сложно пример придумать в чистом MVC, но думаю тоже найдется если подумать.
3.1. Пример без вьюшек уже приводил — когда аджакс запрос, ожидающий данные в json или в вииде строки, любой api почти всегда тоже будет без вьюшек.
3.2. Без контроллера — тоже без проблем, есть модель которая тянет данные со стороннего сервиса через апи, эти данные нужны лишь в отдельном блоке сбоку, но никогда не открываются как отдельная страница.
3.3. Касательно функциональных модулей — я пишу о том же, абсолютно о том же.
4. Вы пишите что больше и этого уже достаточно. Если говорить об урл, то при текущих серверах это пренебрежимо мало и не стоит это относить к недостаткам. Я же писал о том как было ранее — получили данные из БД, они как правило в виде обычного массива, далее оперируют этим массивом. Если передавать массив и он большой, то по умолчанию он будет копироваться и да, будет кушать память. Сейчас же это скорее будет некая коллекция и передаваться будет в виде объекта, а он по умолчанию не будет копироваться и кушать память
4.1. В MVC контроллер не должен разбирать урл. Урл должен разбираться до контроллера, либо как-то напрямую, но лучше в неком классе Request и уже на основе этого урла разобранного как-раз и будет подключаться и вызываться некий метод некого контроллера
Мое понимание CMV это где запрос идет к контроллеру который в свою очередь является как бы посредником между моделью и выводом. То есть контроллер получает данные из модели и отдает их на отображение
Мне интересно, есть ли у кого практический опыт использования Flux?
Это когда есть один «диспечер» на весь проект и все действия происходят только через него, он управляет сохранением данных в разных storage, через которые отрисовываются View.
Это когда есть один «диспечер» на весь проект и все действия происходят только через него, он управляет сохранением данных в разных storage, через которые отрисовываются View.
У меня однажды полностью выстроилось в голове понимание MVC после вот этого видео. (видео на английском).
Знающие товарищи, объясните, пожалуйста, как в рамках MVC сделать список с галочками в desktop варианте. Т.е. например, есть список элементов, и есть кнопка удалить, по которой все отмеченные галочками элементы удаляются из модели. Где хранить эти галочки? Согласно моим представлениям, галочки не являются ни частью модели, ибо модели плевать на какие-то галочки в UI, ни частью View, ибо view достаточно туп и не имеет своего состояния. Controller тоже не имеет состояния. Так куда же их присунуть? ВMVVM/MVP все понятно — за это отвечает VM/P, а тут-то кто?
Где хранить эти галочки?А зачем их хранить?
Или это вопрос из разрада «сохранение состояния приложения»?
Хранить — значит кто их в себе держит, пока экран открыт? Другими словами, по нажатию кнопки Удалить, куда полезет контроллер, чтобы узнать, какие элементы были отмечены галочками, а какие — нет?
А почему контроллер должен куда-то лезть?
Нажатие удалить — отправляет список нажатых галочек в контроллер. Он их получает. POST или GET запросом — в простейшем случае.
Нажатие удалить — отправляет список нажатых галочек в контроллер. Он их получает. POST или GET запросом — в простейшем случае.
Я же сказал, что я про desktop, где нет никакого клиента и севрера. То, что называется active MVC.
подход не меняеться, список отмеченных элементов по кнопке уходит в событие (команду, прямой вызов метода, etc) контроллеру.
Хорошо. Давайте такой пример. На экране есть два списка: один — список доступных элементов и второй — список выбранных элементов. Пользователь выбирает элемент в списке доступных и нажимает кнопку Выбрать, что переносит элемент из списка доступных в список выбранных. При этом из списка доступных он удаляется. Список доступных элементов динамически обновляется, т.е. какое-то событие в фоне может в этот список изменить и UI должен сразу все это отразить. По нажатию OK, окно закрывается и в модели надо что-то с выбранными элементами сделать. Теперь кто хранит список выбранных элементов и формирует список доступных (с учетом того, что выбранные в нем отображаться не должны)?
Не уверен что мое решение правильно ложиться в паттерн MVC, но… при переносе элемена контроллеру отправляется соответствующее событие, которое транслируеться в репозиторий (выступающий в роли ViewModel). При нажатии на кнопку происходит синхронизация VM репозитория с более глобальным.
Второе что приходит на ум и лучше ложиться в MVC это View хранит в себе 2 объекта списка и манипулирует ими на свое усмотрение, по нажатию контроллеру отправляеться нотификация с состоянием Model из View. Ну дальше вы поняли.
Второе что приходит на ум и лучше ложиться в MVC это View хранит в себе 2 объекта списка и манипулирует ими на свое усмотрение, по нажатию контроллеру отправляеться нотификация с состоянием Model из View. Ну дальше вы поняли.
Второе что приходит на ум и лучше ложиться в MVC это View хранит в себе 2 объекта списка и манипулирует ими на свое усмотрение, по нажатию контроллеру отправляеться нотификация с состоянием Model из View. Ну дальше вы поняли.
Вот, мы и подошли что MVC во многих случаях треугольник, а не линейный pipline. Причём в десктоп вариантах нету конца процессу (в веб варианте, конец это готовый html).
>Второе что приходит на ум и лучше ложиться в MVC это View хранит в себе 2 объекта списка и манипулирует ими на свое усмотрение, по нажатию контроллеру отправляеться нотификация с состоянием Model из View. Ну дальше вы поняли.
Вот мы и скатились к тому, что во View появляется логика, чего хотелось бы избежать.
Вот мы и скатились к тому, что во View появляется логика, чего хотелось бы избежать.
модель ничего не хранит, модель описывает поведение данных которые ещё надо инстанцировать т.е. это как class и object.
Т.е. вам надо создать 2 объекта к примеру модели list. При желании std::list в С++ можно обозвать моделью.
В вашем случае эти данные могут иметь отношение исключительно к отображению, и не иметь корней где то в долговременной памяти.
Собственно я и не люблю MVC за то, что только очень узкий круг задач ложится в чистом виде на эту концепцию.
Т.е. вам надо создать 2 объекта к примеру модели list. При желании std::list в С++ можно обозвать моделью.
В вашем случае эти данные могут иметь отношение исключительно к отображению, и не иметь корней где то в долговременной памяти.
Собственно я и не люблю MVC за то, что только очень узкий круг задач ложится в чистом виде на эту концепцию.
>модель ничего не хранит,
ну как это? а откуда данные брать?
>Т.е. вам надо создать 2 объекта к примеру модели list. При желании std::list в С++ можно обозвать моделью.
Ну это уже MVVM какой-то получается. Ну или Application Model, если хотите.
ну как это? а откуда данные брать?
>Т.е. вам надо создать 2 объекта к примеру модели list. При желании std::list в С++ можно обозвать моделью.
Ну это уже MVVM какой-то получается. Ну или Application Model, если хотите.
ну как это? а откуда данные брать?
Простите за каламбур — из данных. Ведь модель это сокращение от «модель данных».
Сбором данных занимается контроллер, иногда модель (есть разные трактовки MC), а данные лежат в БД или генерируются.
Ну это уже MVVM какой-то получается. Ну или Application Model, если хотите.
Всё зависит от того с какой стороны глянуть, и какую роль у вас будет играть контролер. В данном случае похоже получится MV(MVVM)C т.е. в рамках V образовывается своя устойчивая система, которую наверное можно назвать MVVM.
Все таки V работает с состоянием объекта для которого она реализуется (Смотрим в сторону html/js) как ни крути. Другой вопрос чтобы она ни коим образом не влияла на реальные объекты кроме как через контроллер.
>Сбором данных занимается контроллер, иногда модель (есть разные трактовки MC), а данные лежат в БД или генерируются.
Модель и данные в данном случае — это одно и то же. В MVC ведь нет буквы D. И главное, в нормальной архитектуре слой данных спрятан от слоя UI за моделью.
Модель и данные в данном случае — это одно и то же. В MVC ведь нет буквы D. И главное, в нормальной архитектуре слой данных спрятан от слоя UI за моделью.
Модель и данные в данном случае — это одно и то же.
Это всегда разные вещи. Это видимо ещё одно «белое пятно» в MVC, так как о моделях говорим, а где и когда возникают данные никто не говорит.
И главное, в нормальной архитектуре слой данных спрятан от слоя UI за моделью.
Всё зависит от задачи. К тому же в MVC нету UI, так как View это не UI. ^_^
MVC это очень размытый термин, прям как демократия, вроде все понимают, что это но у каждого она своя.
Архитектурных реализаций где есть M,V и C очень много и которые мало имеют общего с тем pipline что описан в статье.
Применительно к вебу у MVC очень много вопросов. К примеру должен ли контролер обрабатывать данные полученные у модели прежде чем передать в V? Кроме того в этой концепции опускается тот факт что в V тоже есть логика (логика отображения), что часто путает юных.
Потом классический холивар о жирном C или жирной M (и то и то верно но применимость зависит от области)?
Ну и я солидарен с авторами Pyramid, что для современного веба, MVC плохо подходит, и по сути является оверинженерингом (применительно к backend).
Архитектурных реализаций где есть M,V и C очень много и которые мало имеют общего с тем pipline что описан в статье.
Применительно к вебу у MVC очень много вопросов. К примеру должен ли контролер обрабатывать данные полученные у модели прежде чем передать в V? Кроме того в этой концепции опускается тот факт что в V тоже есть логика (логика отображения), что часто путает юных.
Потом классический холивар о жирном C или жирной M (и то и то верно но применимость зависит от области)?
Ну и я солидарен с авторами Pyramid, что для современного веба, MVC плохо подходит, и по сути является оверинженерингом (применительно к backend).
Для огромных проектов и столь же больших команд разработчиков подходит очень удачно, так как позволяет проводить разработку практически независимо между командами. Для небольших синглпейджей совершенно согласен, уж слишком раздута инфраструктура, что компенсируеться, правда, отличной расширяемустью и простотой в поддержке. Но ровно тоже самое можно сказать про большинство технологий, паттернов и методологий разработки. Да и не только разработки.
Это вы ответили на мою ремарку на счёт веб, а что на счёт серьёзной путаницы в самом MVC?
Не факт, что без MVC нельзя так же, к тому же для больших команд становится актуальным «блокировка» M. т.е. большой командой независимо править M очень трудно. Вот C и V конечно паралелится лучше.
так как позволяет проводить разработку практически независимо между командами
Не факт, что без MVC нельзя так же, к тому же для больших команд становится актуальным «блокировка» M. т.е. большой командой независимо править M очень трудно. Вот C и V конечно паралелится лучше.
Не факт, что без MVC нельзя так же
Очевидно что можно. MVC это всего лишь 1 из способов решить эту проблему.
к тому же для больших команд становится актуальным «блокировка» M. т.е. большой командой независимо править M очень трудно.
Смотря что мы понимаем по абстрактным слово M. Я понимаю его как аксесоры к неизменным данным (Бд, Сервис, etc). А они очень замечательно паралелятся и не звавязаны на блокировках. Если все же случилась блокировка аксессора то это косяки проектирования и project-managment'а, и к недостаткам паттерна это можно отнести с трудом.
Не очень понимаю.
Я всегда считал что процесс примерно следующий:
Model — это класс описывающий структуру данных в БД (dao.model), также структура данных на странице (controller.model)
View — для Java — JSP, JSF and etc, для .NET это ASP and etc, где расписана бизнес логика поведения данных.
Controller — это метод инициализации страницы, а также все серверные ajax обработчики бизнес логики со страницы.
Service — прослойка содержащая серверную бизнес логику.
DAO — тут думаю понятно.
Я где-то ошибся или вообще о другом говорю?
Я всегда считал что процесс примерно следующий:
Model — это класс описывающий структуру данных в БД (dao.model), также структура данных на странице (controller.model)
View — для Java — JSP, JSF and etc, для .NET это ASP and etc, где расписана бизнес логика поведения данных.
Controller — это метод инициализации страницы, а также все серверные ajax обработчики бизнес логики со страницы.
Service — прослойка содержащая серверную бизнес логику.
DAO — тут думаю понятно.
Я где-то ошибся или вообще о другом говорю?
MVC позволяет, хоть и достаточно жесткими ограничениями, сильно улучшить сопровождаемость кода, не давая понаделать «гибких» решений которых очень хочется понаделать в проекте «бложика». Лет 10 назад мендя просто «достала» гибкость, когда в php миксили и HTML и SQL рядом
Sign up to leave a comment.
Model View Controller (MVC) опыт использования, выводы