Вопрос

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

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

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

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

Возьмем, к примеру, пост Джеффа о MVC:

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

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

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

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

Это было полезно?

Решение

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

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

..и из http://martinfowler.com/eaaDev/uiArchs.html :

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

Другие советы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Редактировать На основании ссылки на Фаулера, его книгу Шаблоны архитектуры корпоративных приложенийe — отличное место для чтения о MVC и других шаблонах.

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top