Я не могу грок MVC, что это такое, а что нет?

Question

Я не могу понять, что такое MVC, какой образ мышления или модель программирования я должен приобрести, чтобы материал MVC мог мгновенно «зажечь» мою голову? Если не сразу, то какие простые программы / проекты я должен попытаться сделать в первую очередь, чтобы я мог применить изящные вещи, которые MVC привносит в программирование.

ООП интуитивно понятнее и проще, объект окружает нас, а преимущества повторного использования кода с помощью ООП-парадигмы мгновенно переходят на любой экран. Вероятно, вы можете поговорить с кем-нибудь об ООП в течение нескольких минут и прочитать несколько примеров, и они получат его. В то время как ООП как-то повышает аспект интуитивности программирования, MVC, похоже, делает наоборот. У меня возникают негативные мысли о том, что некоторые будущие работодатели (или даже клиенты) будут смотреть на меня свысока за то, что я не использую технологию MVC.

Хотя я, вероятно, получаю аспект MVC skinnable , но когда я пытаюсь применить его к моему собственному проекту, я не знаю, с чего начать.

А также некоторые программисты даже расходятся во мнениях о том, как правильно выполнить MVC.

Взять это, например, из поста Джеффа о MVC:

Вид просто, как вы кладете данные, как это отображается. если ты хочу подмножество некоторых данных, для Например, мое мнение таково, что это ответственность модели.

Так что, возможно, некоторые программисты используют MVC, но они каким-то образом непреднамеренно используют View или Controller для извлечения подмножества данных.

Почему у нас нет точного определения того, что и как правильно выполнить MVC?

А также, когда я ищу программы MVC .NET, большинство из них относится к веб-программам, а не к настольным приложениям, это меня еще больше заинтриговало. Я предполагаю, что это наиболее выгодно для веб-приложений, нет проблем с смешанным представлением (html) и контроллером (программным кодом) в настольных приложениях.

Answer 1

Мне нравится, как говорит Мартин Фаулер:)

http://martinfowler.com/eaaCatalog/modelViewController.html

.. и от http://martinfowler.com/eaaDev/uiArchs.html:

Взять Model-View-Controller в качестве примера. Его часто называют шаблоном, но я не нахожу ужасно полезным думать о нем как о шаблоне, поскольку он содержит довольно много разных идей. Разные люди, читающие о MVC в разных местах, берут из этого разные идеи и называют их «MVC». Если это не вызывает достаточной путаницы, вы получаете эффект недопонимания MVC, которое развивается через систему китайского шепота.

Answer 2

Вы можете начать с чтения ответов на этот вопрос .

Answer 3

MVC прекрасно подходит для WebApps. Большинство веб-приложений получают данные из БД, обрабатывают их немного и показывают их пользователю. БД - это уровень вашей модели, контроллер выполняет обработку, а просмотр просто выдает HTML-код.

Некоторые люди думают, что контроллеры должны просто получать данные из модели и передавать их в представление, но я думаю, что это означает, что контроллеры бесполезны и, следовательно, это просто модель программирования MV :) Но я понимаю их, если вы используете какую-то обработку, вы собираетесь использовать ее более одного раза, и поэтому лучше делать это на уровне модели, таким образом ее можно разделить между различными частями приложений.

Вам не нужно использовать MVC для настольных приложений, на самом деле, я не уверен, что эта модель подойдет для огромных приложений, которыми обычно являются настольные. Слишком часто вы хотите использовать «компонент», то есть то, что вы можете передавать одни и те же данные и получать из них один и тот же интерфейс, но в разных частях приложения, и это просто приводит к копированию кода с помощью MVC.

Answer 4

Я обнаружил, что парадигма MVC часто слишком раздутая. Простая модель / представление (без контроллера) проще для понимания и реализации.

Большинство людей понимают, что какой-то класс содержит данные (модель) и логику загрузки / сохранения данных, а другой класс показывает эти данные (представление). Дайте ему немного клея, чтобы загрузить документ (что-то вроде менеджера документов), и все готово.

Answer 5

По своей сути MVC - это просто особый случай разделения интересов: одна часть кода отвечает за хранение данных, вторая часть отвечает за манипулирование данными, а третья заботится о взаимодействии с пользователем.

Любой из этих блоков может быть реализован способом ОО или нет - MVC и ООП ортогональны. (Хотя, по моему опыту, приложения и фреймворки MVC, скорее всего, будут ОО.)

Answer 6

Парадигма MVC - это способ разбить приложение на три части: модель, представление и контроллер. Первоначально MVC был разработан для отображения традиционных ролей ввода, обработки и вывода в область GUI .

Пользовательский ввод, моделирование внешнего мира и визуальная обратная связь с пользователем разделяются и обрабатываются объектами модели, области просмотра и контроллера. Контроллер интерпретирует ввод от мыши и клавиатуры от пользователя и отображает эти пользовательские действия в команды, которые отправляются в модель и / или область просмотра для внесения соответствующих изменений. Модель управляет одним или несколькими элементами данных, отвечает на запросы о его состоянии и отвечает на инструкции по изменению состояния. Окно просмотра управляет прямоугольной областью дисплея и отвечает за представление данных пользователю посредством комбинации графики и текста ... читать дальше & даже больше .

Answer 7

MVC - это шаблон, и он хорошо работает с ООП, они не являются эксклюзивными - я бы сказал, что они были ортогональны. Шаблон MVC пытается отделить код дисплея (V) от данных (M) и потока управления (C).

Если вы ищете «MVC .Net», вы почти наверняка получите много хитов для веб-приложений, потому что недавно была выпущена платформа ASP.Net MVC, и это приложение шаблона MVC для программирования ASP.Net, следовательно, он используется для разработки веб-сайтов. Как вы предполагаете, нет никаких причин не применять этот шаблон и к настольным приложениям.

Если вам трудно работать с MVC, я бы порекомендовал прочитать шаблоны в целом, чтобы понять, как люди говорят о моделировании проблем / решений с использованием шаблонов, а затем более подробно рассмотрим MVC.

Редактировать По подсказке Фаулера, его книга Шаблоны Enterprise Application Architectur e - отличное место для чтения MVC и других шаблонов.

Answer 8

Может быть, следуя статье Википедии , вы можете обратиться к другим реализациям. Он содержит ссылки на реализации MVC в качестве инфраструктуры GUI .

Answer 9

«Типичная» реализация MVC будет иметь:

• представления - предоставляет данные для просмотра конечному пользователю и предоставляет им объекты пользовательского интерфейса для взаимодействия с данными (но не для обработки этого взаимодействия)
• controller (s) - обрабатывает взаимодействие с пользователем и манипулирование данными, перемещающимися между видами и моделью
• модель - обрабатывает хранение данных и представление этих данных для приложения

Частым использованием паттерна MVC будет рендеринг HTML / CSS / браузера для части представления веб-приложения, уровень приложения на языке PHP / сценариев, выполняющий роль контроллера, и MySQL или аналогичная база данных, выступающая в качестве модели (которая может иметь или не иметь какую-то структуру ORM перед ней).

По правде говоря, очень немногие люди используют MVC именно в этом формате, и на то есть веские причины (на мой взгляд). Разные приложения имеют разные потребности и требования к дизайну, и полезно сгибать шаблоны к тому, что необходимо. В наши дни «MVC», по-видимому, описывает в большей степени использование инфраструктуры, которая изолирует уровни приложения, чем конкретный шаблон модель-представление-контроллер.

С точки зрения работодателя, то, что действительно ищут (часто), это тот уровень абстракции и опыт, который получается при создании n-многоуровневого приложения. При переходе от работы в приложении происходит довольно значительный мысленный скачок, который можно разделить не только на вертикальные элементы, но и на горизонтальные слои элементов.

Как примечание, скиннинг - это на самом деле только аспект одного конкретного уровня, вы можете изменить источники данных на уровне модели, методы манипулирования этими данными (например, новый алгоритм) на уровне контроллера и развернуть их постепенно, без необходимости менять другие слои.