Как серьезный программист, как вы отвечаете на вопрос, что такое MVC?
На мой взгляд, MVC - это своего рода туманная тема, и поэтому, если ваша аудитория - ученик, вы можете описать ее в общих терминах, которые вряд ли будут противоречивыми.
Однако, если вы разговариваете с хорошо осведомленной аудиторией, особенно с интервьюером, мне трудно думать о направлении, которое не рискует реакцией «ну, это не правильно! ...». У нас у всех разный реальный опыт, и я не встречал один и тот же шаблон реализации MVC дважды.
В частности, по-видимому, существуют разногласия в отношении строгости, определения компонентов, разделения частей (какая часть подходит, где) и т. Д.
Итак, как мне объяснить MVC таким образом, чтобы он был правильным, кратким и неоспоримым?
источник
Ответы:
MVC - это программная архитектура - структура системы, которая отделяет логику домена / приложения / бизнеса (что вы предпочитаете) от остальной части пользовательского интерфейса. Это делается путем разделения приложения на три части: модель, представление и контроллер.
Модель управляет фундаментальным поведением и данными приложения. Он может отвечать на запросы о предоставлении информации, отвечать на инструкции по изменению состояния своей информации и даже уведомлять наблюдателей в управляемых событиями системах при изменении информации. Это может быть база данных или любое количество структур данных или систем хранения. Короче говоря, это данные и управление данными приложения.
Представление эффективно предоставляет элемент пользовательского интерфейса приложения. Он отобразит данные из модели в форму, подходящую для пользовательского интерфейса.
Контроллер получает пользовательский ввод и выполняет вызовы к модельным объектам и представлению для выполнения соответствующих действий.
В целом, эти три компонента работают вместе, чтобы создать три основных компонента MVC.
источник
аналогия
Я объяснил MVC моему папе так:
MVC (Модель, Представление, Контроллер) - это шаблон для организации кода в приложении для улучшения удобства сопровождения.
Представьте себе фотографа с его камерой в студии. Клиент просит его сфотографировать коробку.
Коробка - это модель , фотограф - это контроллер, а камера - это вид .
Поскольку коробка не знает о камере или фотографе, она полностью независима. Такое разделение позволяет фотографу обойти рамку и направить камеру под любым углом, чтобы получить желаемый снимок / вид.
Не-MVC архитектуры, как правило, тесно связаны друг с другом. Если бы коробка, контроллер и камера были одним и тем же объектом, то нам пришлось бы разбирать и затем заново собирать и коробку, и камеру каждый раз, когда мы хотели получить новый вид. Кроме того, фотографировать - это все равно, что делать селфи, а это не всегда легко.
Детальное объяснение
Только после прочтения следующего вопроса / ответа из списка рассылки я почувствовал, что понял MVC. Цитата: https://mail.python.org/pipermail/python-list/2006-January/394968.html
источник
MVC - это в основном модное слово.
Раньше его считали шаблоном, но его первоначальное определение 1979 года было тупым, переданным, неправильно истолкованным, вырванным из оригинального контекста. Он был плохо переопределен до такой степени, что начинает напоминать религию, и хотя это, безусловно, помогает его культовым грузчикам защищать его, его имя больше не ассоциируется с твердым набором руководящих принципов . Как таковой, он не может больше рассматриваться как образец.
MVC никогда не предназначался для описания веб-приложений.
Ни современные операционные системы, ни языки.
(некоторые из них фактически сделали определение 1979 года излишним)
Это было сделано для. И это не сработало.
Теперь мы имеем дело с непристойным гибридом web-mvc, который с его ужасным статусом модных слов, плохим определением и полуграмотными программистами в качестве целевой демографии делает действительно плохую рекламу шаблонам программного обеспечения в целом.
Таким образом, MVC стал разделением интересов для людей, которые на самом деле не хотят слишком много думать об этом.
Веб-сайты / веб-приложения в 90-х не использовались для разделения задач.
Они были ужасными порциями смешанного кода спагетти.
Изменения пользовательского интерфейса, изменения дизайна и перестановки данных были невероятно сложными, дорогими, длинными, удручающими, злополучными.
Веб-технологии, такие как ASP, JSP и PHP, позволяют слишком легко смешивать представления о проблемах с данными и приложениями. Вновь прибывшие на поле обычно испускают неразборчивый код грязных шаров, как в те старые времена.
Таким образом, все большее число людей начали повторять «использовать MVC» в бесконечных циклах на форумах поддержки. Число людей расширилось до уровня менеджеров и маркетологов (для некоторых этот термин уже был знаком с тех времен в программировании на графическом интерфейсе, в которых шаблон имел смысл), и это стало чудовищем модного слова, с которым мы сейчас сталкиваемся ,
Это здравый смысл , а не методология .
Это отправная точка , а не решение .
Это все равно, что говорить людям дышать воздухом или делать хруст , а не лекарство от рака .
источник
It's a fancy word for pre-existing concepts that didn't really need one.
И какой шаблон дизайна / архитектура не подходит под это описание?The data model is handled one way, the view in another, the rest is just named "controller"
+1Лучший способ определить это - обратиться к оригинальным работам Трюгве Реенскауг , который изобрел его: http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html.
Этот документ, в частности, обычно считается текстом определения: http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf
источник
MVC - это шаблон проектирования, используемый для изоляции бизнес-логики от представления.
Он отличается от многих других шаблонов проектирования тем, что обычно он не кратко реализован, а является основой фреймворка.
В то время как приложение, реализующее шаблон стратегии, является лишь небольшой деталью, утверждение о том, что веб-приложение использует шаблон проектирования MVC, очень определяет его архитектуру .
источник
MVC - проект программного обеспечения, который разделяет следующие компоненты системы или подсистемы:
источник
Я бы сказал, что MVC - это концепция или семейство похожих шаблонов.
Я думаю, что эту статью стоит прочитать. Архитектура GUI Мартина Фаулера
источник
Во-первых, вы должны определить, кто задает вопрос и какой ответ он ищет. Вы отвечаете на этот вопрос другим вопросом, например, «В каком смысле?»
Вы можете спросить, ссылаются ли они на MVC вообще, на конкретную реализацию MVC (то есть asp.net MVC, spring MVC, smalltalk MVC и т. Д.), Что это такое технически, что это философски (да, у него есть философия)
Если это вопрос теста, и вы не можете попросить его уточнить, то вам придется угадывать, исходя из контекста.
Хороший простой ответ:
Вы также можете сказать:
Но, в конце концов, вы будете судить, дадите ли вы ожидаемый ответ. Единственное решение проблемы - выяснить, какого ответа они ожидают.
источник
Вот что я бы сказал по этому поводу. Я бы попытался объяснить это с точки зрения мобильных приложений, потому что это то, с чем я больше всего знаком, и потому что я не думаю, что полностью понял это до того, как начал делать мобильные приложения.
Давайте возьмем Android для примера.
Презентационный слой, т.е. Пользовательский интерфейс может (должен чаще всего) быть указан полностью в XML. Для простоты предположим, что один XML-файл описывает один экран в приложении. XML-файл определяет элементы управления, расположение элементов управления, расположение, цвета, размер, строковые метки ... все, что касается представления. Тем не менее, он ничего не знает о том, когда он будет вызван, когда он будет размещен на экране. Это будет автономный макет или часть более крупного макета? Вот вам и ваш идеальный ВИД .
Теперь, видимо, нужно в какой-то момент поместить его на экран, так как это сделать? Ваш КОНТРОЛЛЕР в Android называется Activity. Как следует из названия, активность делает некоторую активность. Даже если его единственной целью является отображение вида, определенного на шаге 1, он выполнит некоторое действие. Итак, активность выбирает представление и отображает его на экране. Поскольку представление ничего не знает о деятельности, так же как и деятельность ничего не знает о фактическом представлении. Мы (программисты) могли несколько раз перестраивать компоновку представления, не меняя ни одной строчки кода в нашей деятельности.
Теперь, нет ничего особенного в том, чтобы представить свой красивый блестящий, четко определенный макет XML без каких-либо действий. Допустим, мы хотим сохранить данные, введенные пользователем. Деятельность должна решать этот процесс от передачи данных от пользователя до передачи их кому-то другому для обработки (обработки, сохранения, удаления). К кому это перейдет? Ну, к МОДЕЛИ . Мне нравится думать о модели как о чистой. Java- класс, который ничего не знает о контексте приложения, в котором он живет. (На практике это почти никогда не будет иметь место).
Допустим, у меня есть класс Person, у которого есть три свойства: имя, адрес, возраст. В моем XML-макете есть 3 поля для ввода пользователя: имя, адрес, возраст. Моя деятельность берет три значения из пользовательского ввода, создает новый объект Person и вызывает для него некоторый метод, который знает, как обрабатывать некоторую логику, специфичную для человека. Там у вас есть это. Model-View-Controller.
источник
Я всегда начинаю с того, что говорю им, что шаблон не является чем-то новым и существует уже много лет ... в этот момент они бросают на меня пытливый взгляд и БАМ!
И затем я бы довольно много говорил о различных моментах, таких как предыдущие ответы, но я думаю, что важно также быть контекстным, как сказал JB King, ASP.NET MVC и т. Д.,
источник