Comments 26
В каконическом виде
Оговорочка по Фрейду…
request/response парадигма, IMHO, вообще не очень вяжется в MVC.
Но я не настолько глубоко и серьезно исследовал этот вопрос, чтобы делать однозначные выводы.
Надо вначале покурить парадигму.
Но я не настолько глубоко и серьезно исследовал этот вопрос, чтобы делать однозначные выводы.
Надо вначале покурить парадигму.
Объект != Модель
Вы не понимаете MVC.
Модель — это в первую очередь описание бизнес-процесса (Модель бизнес-логики)
А вот способ хранения данных и проецирование их в объекты относятся к другой задаче.
К задаче декомпозирования Model.
Есть два подхода(которые знаю я):
— Active Record
— Data Mapping.
Более развернуты ответ можете прочитать в комментариях в указанном вами топике.
Вы не понимаете MVC.
Модель (англ. Model). Модель предоставляет знания: данные и методы работы с этими данными, реагирует на запросы, изменяя своё состояние. Не содержит информации, как эти знания можно визуализировать.
Модель — это в первую очередь описание бизнес-процесса (Модель бизнес-логики)
А вот способ хранения данных и проецирование их в объекты относятся к другой задаче.
К задаче декомпозирования Model.
Есть два подхода(которые знаю я):
— Active Record
— Data Mapping.
Более развернуты ответ можете прочитать в комментариях в указанном вами топике.
То что вы принимаете за MVC — на самом деле MVP:
ru.wikipedia.org/wiki/Model-View-Presenter
ru.wikipedia.org/wiki/Model-View-Presenter
Берем любую книгу по паттернам. Мне попалась Applied Java™ Patterns (Stephen Stelting, Olav Maassen).
Открываем паттерн MVC.
Читаем:
Implementing the MVC pattern requires the following components:
Model – This component contains one or more classes and interfaces that are responsible for maintaining the
data model. The state of the model is kept in attributes and the implementation of methods. To be able to notify
view components of any change in the model, the model keeps a reference to each registered view (there can be
more than one at the same time). When a change occurs, every view component that has registered should be
notified.
View – The classes and interfaces of the view provide a representation of the data in the model component. The
view may consist of visual GUI components, but is not required to. A view must be registered with the model to
be notified of changes to the model data. When a notification of such a change is received, the view component is
responsible for determining if and how to represent this change.
The view component also keeps a reference to the model to retrieve data from the model, but it can only retrieve
information, not change it. The view can also be used to render the controller, but requests for change are always
forwarded to a controller component; so the view needs to keep a reference to one or more controllers.
Controller – This component manages changes to the model. It keeps a reference to the model component who
is responsible for carrying out the change, whereas the controller calls one or more update methods. The requests
for change may come from a view component.
Открываем паттерн MVC.
Читаем:
Implementing the MVC pattern requires the following components:
Model – This component contains one or more classes and interfaces that are responsible for maintaining the
data model. The state of the model is kept in attributes and the implementation of methods. To be able to notify
view components of any change in the model, the model keeps a reference to each registered view (there can be
more than one at the same time). When a change occurs, every view component that has registered should be
notified.
View – The classes and interfaces of the view provide a representation of the data in the model component. The
view may consist of visual GUI components, but is not required to. A view must be registered with the model to
be notified of changes to the model data. When a notification of such a change is received, the view component is
responsible for determining if and how to represent this change.
The view component also keeps a reference to the model to retrieve data from the model, but it can only retrieve
information, not change it. The view can also be used to render the controller, but requests for change are always
forwarded to a controller component; so the view needs to keep a reference to one or more controllers.
Controller – This component manages changes to the model. It keeps a reference to the model component who
is responsible for carrying out the change, whereas the controller calls one or more update methods. The requests
for change may come from a view component.
Так что нотификация вида об изменениях через события модели — обязательная часть MVC.
Иначе это уже что-то другое (возможно, также успешное, но другое).
Иначе это уже что-то другое (возможно, также успешное, но другое).
Ну да, MVC более применима к GUI, например
Туда замечательно вписывается event bus — есть модели, которые генерируют события, на которые подписаны компоненты.
При действиях юзера генерируются другие события, на которые подписаны контроллеры.
Туда замечательно вписывается event bus — есть модели, которые генерируют события, на которые подписаны компоненты.
При действиях юзера генерируются другие события, на которые подписаны контроллеры.
Весь смысл MVC в современном вебе нужно сводить к разделению кода на компоненты, каждый из которых занимается только своей частью работы. Если работает принцип замещения лискоу, то вообще замечательно.
А что значит каждая буква и какие должны быть компоненты — это уже зависит от приложения и личных пристрастий команды разработчиков.
А что значит каждая буква и какие должны быть компоненты — это уже зависит от приложения и личных пристрастий команды разработчиков.
Не соглашусь.
Каждый термин из аббревиатуры четко детерминирован.
ru.wikipedia.org/wiki/Model-View-Controller
Каждый термин из аббревиатуры четко детерминирован.
ru.wikipedia.org/wiki/Model-View-Controller
Ага, а вы ещё пример посмотрите, который показывает, что помимо так называемого контроллера используется логика i18n, флэш сообщения, объект доступа, реквест, объект для работы со списком, мэппер как составная часть Модели и т.д.
Не говоря уже о том, что MVC вовсе описывает не вебсущнности и в вебе не может быть применим один в один.
Не надо загоняться по точным формулировкам, нужно всё делать удобно.
Не говоря уже о том, что MVC вовсе описывает не вебсущнности и в вебе не может быть применим один в один.
Не надо загоняться по точным формулировкам, нужно всё делать удобно.
Что значит загоняться по формулировкам.
Термины четко отражают скрытое в них значение.
Пример не смотрел, лишь определениями и меня они частично удовлетворили.
Суть в том, что бы правильно понимать то что вы используете.
Если делать так, как больше нравится, то и называть это надо правильно. Не MVC, а НСГ(«нам стрельнуло в голову»).
Уже сколько наблюдаю на хабре техническую безграмотность в применении терминологии, которая в свою очередь перерастает в не понимании технологии в принципе. Т.к. если человек не понимает, того что он читает, то как он сможет освоить и применить это корректно?
Не смотря на то что MVC разрабатывался не к веб, он все равно подходит. Только вот понимать его нужно правильно(читать научиться терминологию). Согласен, что в веб-разработке он не достаточно детально описывает подходы, но он не позволяет делать то, что творят горе-разработчика, а именно пихать бизнес-логику в контроллеры или в представление.
Если грубо, то MVC разделяет разработку продукта а следующие слои:
Model — описание бизнес-логики
View — отображение данных
Controller — валидация введенных данных и выбор отображения
Все четко и понятно, не надо изврещений типа:
Программирование и так формализовано из рук вон плохо, все делается по наитию. Не надо привносить ещё больший хаос, стремиться нужно к пониманию технологии и развитию.
Где бы сейчас было строительство если бы не было ГОСТов?
P.S.
Соглашусь, пример отвратный в Wiki. Наверное я его перепишу и отправлю на подтверждение.
Термины четко отражают скрытое в них значение.
Пример не смотрел, лишь определениями и меня они частично удовлетворили.
Суть в том, что бы правильно понимать то что вы используете.
Если делать так, как больше нравится, то и называть это надо правильно. Не MVC, а НСГ(«нам стрельнуло в голову»).
Уже сколько наблюдаю на хабре техническую безграмотность в применении терминологии, которая в свою очередь перерастает в не понимании технологии в принципе. Т.к. если человек не понимает, того что он читает, то как он сможет освоить и применить это корректно?
Не смотря на то что MVC разрабатывался не к веб, он все равно подходит. Только вот понимать его нужно правильно(читать научиться терминологию). Согласен, что в веб-разработке он не достаточно детально описывает подходы, но он не позволяет делать то, что творят горе-разработчика, а именно пихать бизнес-логику в контроллеры или в представление.
Если грубо, то MVC разделяет разработку продукта а следующие слои:
Model — описание бизнес-логики
View — отображение данных
Controller — валидация введенных данных и выбор отображения
Все четко и понятно, не надо изврещений типа:
Не надо загоняться по точным формулировкам, нужно всё делать удобно.
Программирование и так формализовано из рук вон плохо, все делается по наитию. Не надо привносить ещё больший хаос, стремиться нужно к пониманию технологии и развитию.
Где бы сейчас было строительство если бы не было ГОСТов?
P.S.
Соглашусь, пример отвратный в Wiki. Наверное я его перепишу и отправлю на подтверждение.
Я бы мог пофлеймить об сомнительности вашего описания MVC, что в очередной раз бы доказало о сомнительной пользе чёткой попытки разделить всё на конкретные три буквы, но лучше сошлюсь на Фаулера, как серьёзного эксперта по паттернам.
martinfowler.com/eaaDev/uiArchs.html
>> Frankly a lot of the reason for this is that parts of classic MVC don't really make sense for rich clients these days.
>>At the heart of MVC, and the idea that was the most influential to later frameworks, is what I call __Separated Presentation__.
Жесткие ГОСТы породили массу серых и безликих зданий, в то время как много веков назад строились дворцы и пирамиды, которые дожили до нашего времени. Я не говорю что стандарты это плохо, я говорю, что стандарты должны быть гибкими, потому что для достижения целей иногда можно их немного видоизменить под проект.
martinfowler.com/eaaDev/uiArchs.html
>> Frankly a lot of the reason for this is that parts of classic MVC don't really make sense for rich clients these days.
>>At the heart of MVC, and the idea that was the most influential to later frameworks, is what I call __Separated Presentation__.
Жесткие ГОСТы породили массу серых и безликих зданий, в то время как много веков назад строились дворцы и пирамиды, которые дожили до нашего времени. Я не говорю что стандарты это плохо, я говорю, что стандарты должны быть гибкими, потому что для достижения целей иногда можно их немного видоизменить под проект.
Вы сослались на Фаулера и выделели цитату, которая ровным счетем ничего не говорит, кроме того, что в MVC главное идея, зовущаяся «Separated Presentation»
Давайте подискутируем по поводу моего описания MVC, с чем вы не согласны?
На счет ГОСТов. Если бы их не было, то рушились бы сооружения. ГОСТ не ограничивает гибкость, он задает правила стандарты, при проектировании.
Тоже самое и MVC.
Давайте подискутируем по поводу моего описания MVC, с чем вы не согласны?
На счет ГОСТов. Если бы их не было, то рушились бы сооружения. ГОСТ не ограничивает гибкость, он задает правила стандарты, при проектировании.
Тоже самое и MVC.
Угу, я выделил цитату, которую я сам озвучил в первом посте.
Я привёл примеры с пирамидами, которые строились без госта и пережили многие здания построенные по ним. Даже сейчас госты на строительства в разных странах разные, из-за этого должны рушиться здания?
>>Давайте подискутируем по поводу моего описания MVC, с чем вы не согласны?
Задолбало дискутировать ниочём, я предпочитаю обмениваться ссылками на экспертные источники и руководиться собственным опытом, а не в сотый раз объяснять, что идея MVC это понятие недетерминированное, а всего лишь один из тысяч паттернов которые можно использовать при построении приложения, а можно НЕ использовать.
Я привёл примеры с пирамидами, которые строились без госта и пережили многие здания построенные по ним. Даже сейчас госты на строительства в разных странах разные, из-за этого должны рушиться здания?
>>Давайте подискутируем по поводу моего описания MVC, с чем вы не согласны?
Задолбало дискутировать ниочём, я предпочитаю обмениваться ссылками на экспертные источники и руководиться собственным опытом, а не в сотый раз объяснять, что идея MVC это понятие недетерминированное, а всего лишь один из тысяч паттернов которые можно использовать при построении приложения, а можно НЕ использовать.
а не в сотый раз объяснять, что идея MVC это понятие недетерминированное,
Это для вас оно не детерминированное, потому что вы не понимаете что такое MVC.
Даже ссылаясь на Фулера, вы подтвердили это. Т.к. он пишет лишь о том, что в MVC удачная идея «Separated Presentation», но не более того!
Вы же умудряетесь говоря про «Separated Presentation» утверждать, что это и есть MVC.
Вы возможно хороший программист и прекрасно понимаете(чувствуете) как нужно разделить приложение на раздельные представления, но сам термин MVC вам не понятен.
P.S.
Мне очень хочется добиться, что бы люди перестали называть все что не поподя MVC подходом, лишь потому что им так стрельнуло в голову. Что бы не приписывали к «своему» выдуманному подходы минусы MVC используя некоторые его подходы при разработке.
Это для вас оно не детерминированное, потому что вы не понимаете что такое MVC.
Даже ссылаясь на Фулера, вы подтвердили это. Т.к. он пишет лишь о том, что в MVC удачная идея «Separated Presentation», но не более того!
Вы же умудряетесь говоря про «Separated Presentation» утверждать, что это и есть MVC.
Вы возможно хороший программист и прекрасно понимаете(чувствуете) как нужно разделить приложение на раздельные представления, но сам термин MVC вам не понятен.
P.S.
Мне очень хочется добиться, что бы люди перестали называть все что не поподя MVC подходом, лишь потому что им так стрельнуло в голову. Что бы не приписывали к «своему» выдуманному подходы минусы MVC используя некоторые его подходы при разработке.
Вот Вам ещё одна «неудачная» ссылка en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller, там опять же в первой же строке пишется о том, что это паттерн разделения слоёв. С 70-х годов много воды утекло и сейчас многие предпочитают именно эту формулировку, не затачиваясь на аббревиатуре. Мой опыт работы подсказывает то же. Кроме этого я эту практику и формулировку прививаю джуниорам и их архитектурный скилл от этого только выигрывает, потому что они изначально не зажаты в три стены и не стесняются вводить дополнительные сущности.
Раз уз пошла пьёнка о моём непонимани…
>>Controller — валидация введенных данных и выбор отображения
Видите, вы постеснялись ввести сущность валитатор, причём часть валидаций может делать только модель, т.к. она знает о схеме данных. Вы повесили на контроллер выбор вида, хотя это логика отображения и вид вполне себе может сам на основе данных понять как он должен отобразиться.
>>View — отображение данных
В изначальном MVC говорится что модель может посылать сигналы тому же контроллеру в чём вы убедитесь кликнув по ссылке martinfowler.com/eaaCatalog/modelViewController.html, клик как раз и есть такой сигнал.
>>Model — описание бизнес-логики
Бизнес логика — это размытое понятие, view тоже выполняет бизнес логику отображения. Как правило модель в старых описаниях сводили к хранению и извлечению данных и изображали в виде дисков-накопителей.
Так что этот паттерн никогда не был чётким и делать его таковым незачем, так как это только мешает, а идея сформировалась чтобы помогать.
Раз уз пошла пьёнка о моём непонимани…
>>Controller — валидация введенных данных и выбор отображения
Видите, вы постеснялись ввести сущность валитатор, причём часть валидаций может делать только модель, т.к. она знает о схеме данных. Вы повесили на контроллер выбор вида, хотя это логика отображения и вид вполне себе может сам на основе данных понять как он должен отобразиться.
>>View — отображение данных
В изначальном MVC говорится что модель может посылать сигналы тому же контроллеру в чём вы убедитесь кликнув по ссылке martinfowler.com/eaaCatalog/modelViewController.html, клик как раз и есть такой сигнал.
>>Model — описание бизнес-логики
Бизнес логика — это размытое понятие, view тоже выполняет бизнес логику отображения. Как правило модель в старых описаниях сводили к хранению и извлечению данных и изображали в виде дисков-накопителей.
Так что этот паттерн никогда не был чётким и делать его таковым незачем, так как это только мешает, а идея сформировалась чтобы помогать.
Вот Вам ещё одна «неудачная» ссылка en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller, там опять же в первой же строке пишется о том, что это паттерн разделения слоёв.
Боже ш ты мой, зачем вы все выдергиваете из контекста? Могли бы вообще из определения первое слово лишь оставить. Давайте насладимся полным описанием:
Model–View–Controller (MVC) is a computer software design pattern that separates the representation of information from the user's interaction with it.[1][2]
The model consists of application data and business rules, and the controller mediates input, converting it to commands for the model or view.[3]
A view can be any output representation of data, such as a chart or a diagram. Multiple views of the same data are possible, such as a pie chart for management and a tabular view for accountants. The central idea behind MVC is code reusability and separation of concerns. [4]
Всё ваше не понимание текста, потому что вы не желаете понимать смысл терминов.
Прежде чем писать дальше, про ознакомьтесь с документом, где чётко описана парадигма:
www.itu.dk/courses/VOP/E2005/VOP2005E/8_mvc_krasner_and_pope.pdf
Если что-то действительно вам есть сказать по существу, без вырывания слов из контекста, то прошу. Если же нет, то надеюсь вы признаетесь самому себе, что кое что в этом мире вы понимали не так и ваши junior's вместе с вами начнут открывать прекрасный мир программирования по новому.
Ничего не вырвано, я указал что о разделении говорится в первой же строке, а так же упомянул об неактуальности аббревиатуры. А выше ещё писал что в вебе этот паттерн и вовсе другой, так как слои другие. Кстати, а в последнем абзаце опять же говорится о том, что центральной идеей является разделение, а не деление на m, v и с.
Любой кто имел нормальный опыт разработки знает, что в реальных проектах слоёв гораздо больше. А «прекрасный мир» с тремя слоями у нас остался где-то в районе университета и их лабораторий, где этого хватало. Не надо заучивать паттерны, нужно учиться пользоваться их идеями, а не сводить всё к одной единственно правильной реализации.
Любой кто имел нормальный опыт разработки знает, что в реальных проектах слоёв гораздо больше. А «прекрасный мир» с тремя слоями у нас остался где-то в районе университета и их лабораторий, где этого хватало. Не надо заучивать паттерны, нужно учиться пользоваться их идеями, а не сводить всё к одной единственно правильной реализации.
Хорошо, уповайте на свой опыт и не читайте документы, где представлена парадигма(в данном случае MVC)
Вы не понимаете что систему можно рассматривать в различных аспектах. То что центральной идей парадигмы является разделение не отменяет того, что ей присущи многие другие идеи.
Например, тот же MVP шаблон тоже имеет в себе центральной идей разделение слоев, и вы что, будете утверждать что они одинаковые?
(ремарка. советую посмотреть на сноску под цифрой 4, на которую ссылается утверждение про центральную идею разделение проблем)
Это как в математике. Есть необходимое условие, а есть необходимое и достаточное.
Так вот разделение, это необходимое условие, а ни как не необходимое и достаточное.
Вы до сих пор не можете понять, что с подобными утверждениями я не спорил. К чему вы его привели вообще не понятно. Это похоже на то, как вы внезапно решили поговорить про погоду.
Я желаю видеть в людях понимания того что они говорят. А вы же пытаетесь приплести аббревиатуру MVC ко всему, что им не является. Это как называть Бегемота Жирафом и утверждать, что в мире много животных, не только Бегемоты и все они в какой то мере Жирафы.
P.S.
Я устал бороться с людьми, которые не желают смотреть оригинал и не понимать то что написано черным по белому.
Кстати, а в последнем абзаце опять же говорится о том, что центральной идеей является разделение, а не деление на m, v и с.
Вы не понимаете что систему можно рассматривать в различных аспектах. То что центральной идей парадигмы является разделение не отменяет того, что ей присущи многие другие идеи.
Например, тот же MVP шаблон тоже имеет в себе центральной идей разделение слоев, и вы что, будете утверждать что они одинаковые?
(ремарка. советую посмотреть на сноску под цифрой 4, на которую ссылается утверждение про центральную идею разделение проблем)
Это как в математике. Есть необходимое условие, а есть необходимое и достаточное.
Так вот разделение, это необходимое условие, а ни как не необходимое и достаточное.
Любой кто имел нормальный опыт разработки знает, что в реальных проектах слоёв гораздо больше. А «прекрасный мир» с тремя слоями у нас остался где-то в районе университета и их лабораторий, где этого хватало. Не надо заучивать паттерны, нужно учиться пользоваться их идеями, а не сводить всё к одной единственно правильной реализации.
Вы до сих пор не можете понять, что с подобными утверждениями я не спорил. К чему вы его привели вообще не понятно. Это похоже на то, как вы внезапно решили поговорить про погоду.
Я желаю видеть в людях понимания того что они говорят. А вы же пытаетесь приплести аббревиатуру MVC ко всему, что им не является. Это как называть Бегемота Жирафом и утверждать, что в мире много животных, не только Бегемоты и все они в какой то мере Жирафы.
P.S.
Я устал бороться с людьми, которые не желают смотреть оригинал и не понимать то что написано черным по белому.
Что за бред. Какое отношение оригинал имеет к ВЕБу, вы перечитайте ссылку на pdf-ку, перечитайте название статьи «web и MVC» и перечитайте мой пост с которым вы начали спорить — «Весь смысл MVC в современном вебе». Если я пытаюсь сравнить бегемота с жирафом, то вы пытаетесь его сравнить с птеродактелем.
Оригинал я читал, но там описан паттерн не для веба.
Оригинал я читал, но там описан паттерн не для веба.
Дамс.
Можете дальше упираться.
Может все же начнете терминологию учить? Вообще то это базис любого предмета.
Почему рожали документ больше 8 лет? Потому что люди понимают, что нужно выводить базовые понятия парадигмы и приводить её к общему виду.
MVC там (в документе) четко сформулирована. Т.е. вывели парадигму для разработки программного продукта в любом его проявлении.
Сюда же попал и веб.
А ваша отсебятена, которая ни имеет никакой обосновательной базы уже надоела, честное слово.
На сем я заканчиваю дискуссию. Если кто хочет развить тему, что-то уточнить, опровергнуть некоторые слова — прошу в личку.
Можете дальше упираться.
Может все же начнете терминологию учить? Вообще то это базис любого предмета.
Почему рожали документ больше 8 лет? Потому что люди понимают, что нужно выводить базовые понятия парадигмы и приводить её к общему виду.
MVC там (в документе) четко сформулирована. Т.е. вывели парадигму для разработки программного продукта в любом его проявлении.
Сюда же попал и веб.
А ваша отсебятена, которая ни имеет никакой обосновательной базы уже надоела, честное слово.
На сем я заканчиваю дискуссию. Если кто хочет развить тему, что-то уточнить, опровергнуть некоторые слова — прошу в личку.
Паттерн появился когда ещё веба и в помине не было, так что не надо фантазировать. Свои слова о «разделении» я подтверждал выдержками из википедии и фаулера. но вы предпочитаете концентрироваться лишь на трёх буквах конкретной реализации, при чём как я продемонстрировал выше даже сами не можете чётко разделить их по буквам.
Терминологию я прекрасно знаю, как и пару десятков её разъяснений и реализаций, поэтому и воспринимаю паттерн именно так, потому что на опыте ни разу не удалось отделаться лишь тремя слоями, возможно паттерн был самодостаточен в те времена, но сейчас это как реализовывать singleton, забывая о многопоточности используемого языка.
Терминологию я прекрасно знаю, как и пару десятков её разъяснений и реализаций, поэтому и воспринимаю паттерн именно так, потому что на опыте ни разу не удалось отделаться лишь тремя слоями, возможно паттерн был самодостаточен в те времена, но сейчас это как реализовывать singleton, забывая о многопоточности используемого языка.
Это будет не MVC (см. мой комментарий выше).
Оно может хорошо работать, зарекомендовать себя на практике, то тем не менее это не MVC.
И каждый подобный вид взаимодействия имеет смысл рассматривать отдельно от других. Какие-то решения могут быть паттернами, какие-то — скорее, единичными явлениями.
Если же рассматривать MVC как концепцию… То необходимо ее как-нибудь адекватно назвать. MVC уже используется как наименование четко описанного паттерна, давайте так и оставим, чтобы можно было сослаться на первоисточник и говорить об одном и том же.
Так что жду предложений по наименованию концепции.
Оно может хорошо работать, зарекомендовать себя на практике, то тем не менее это не MVC.
И каждый подобный вид взаимодействия имеет смысл рассматривать отдельно от других. Какие-то решения могут быть паттернами, какие-то — скорее, единичными явлениями.
Если же рассматривать MVC как концепцию… То необходимо ее как-нибудь адекватно назвать. MVC уже используется как наименование четко описанного паттерна, давайте так и оставим, чтобы можно было сослаться на первоисточник и говорить об одном и том же.
Так что жду предложений по наименованию концепции.
Данный топик вроде как раз и служит ответом на новый паттерн, заменяющий «устаревший» MVC, сейчас выдвигают MOVE, тем самым просто увеличивают паттерновскую энтропию. Даже в первых книгах по паттернам упоминается что многие паттерны похожи между собой, а мой тимлид в своё время утверждал что половину паттернов можно свести к стратегии.
Тем более вся беда вокруг MVC связана с тем, что в вебе он притянут за уши и не может быть таким же как на декстопе и опять же появляется MVP и т.д. Так что удобнее свести всю эту кучу до понятия простого понятие — разделения слоёв(ответственностей).
Тем более вся беда вокруг MVC связана с тем, что в вебе он притянут за уши и не может быть таким же как на декстопе и опять же появляется MVP и т.д. Так что удобнее свести всю эту кучу до понятия простого понятие — разделения слоёв(ответственностей).
Здесь не слои. Слои располагаются друг за другом, и общаются только с соседними слоями.
В web-модели приложения же и контроллер, и вид обращаются к одним и тем же данным.
Так что если считать данные моделью, то концепция слоев нарушается. Поэтому хочется четкой терминологии.
Если же вообще отказаться от понятия модели, и ввести понятия «провайдер данных» и «операция», то эта модель приложения хорошо ложится на request/response-архитектуру.
В web-модели приложения же и контроллер, и вид обращаются к одним и тем же данным.
Так что если считать данные моделью, то концепция слоев нарушается. Поэтому хочется четкой терминологии.
Если же вообще отказаться от понятия модели, и ввести понятия «провайдер данных» и «операция», то эта модель приложения хорошо ложится на request/response-архитектуру.
Sign up to leave a comment.
web и MVC: разбор полетов