Mvc архитектура это: MVC: Model-View-Controller

Содержание

Что такое MVC: рассказываем простыми словами

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

  • Что такое модель MVC: теория
  • Разбираем MVC на примере магазина сэндвичей
  • Паттерн MVC в реальной веб-разработке: как работает контроллер
  • Модель
  • Представление
  • Заключение

Что такое модель MVC: теория

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

MVC расшифровывается как «модель-представление-контроллер» (от англ. model-view-controller). Это способ организации кода, который предполагает выделение блоков, отвечающих за решение разных задач. Один блок отвечает за данные приложения, другой отвечает за внешний вид, а третий контролирует работу приложения.

Компоненты MVC:

  • Модель — этот компонент отвечает за данные, а также определяет структуру приложения. Например, если вы создаете To-Do приложение, код компонента model будет определять список задач и отдельные задачи.
  • Представление — этот компонент отвечает за взаимодействие с пользователем. То есть код компонента view определяет внешний вид приложения и способы его использования.
  • Контроллер — этот компонент отвечает за связь между model и view. Код компонента controller определяет, как сайт реагирует на действия пользователя. По сути, это мозг MVC-приложения.

Разбираем MVC на примере магазина сэндвичей

Мы уже рассматривали работу с вложенными коллбэками на примере приготовления гамбургеров. Продолжаем традицию: разберем паттерн MVC на примере магазина сэндвичей.

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

У поваров под рукой есть разные продукты: тунец, индейка, ветчина, сыр, листья салата и другие ингредиенты, которые добавляют в бутерброды. Они выбирают только то, что нужно для вашего сэндвича с индейкой. Вы получаете свой заказ.

Покупку бутерброда можно описать через MVC:

  • Модель: кухня, на которой повар делает сэндвич
  • Представление: готовый бутерброд, который вы с удовольствием едите
  • Контроллер: продавец или бармен, который принимает заказ и передаёт его на кухню.

Вы уже представляли готовый сэндвич с индейкой, когда заказывали его бармену. Это представление или view.

Точно так же можно представить взаимодействие с сайтом. Когда вы заходите на сайт Хекслета и переходите по ссылке «Истории успеха», то заранее представляете результат перехода по ссылке. Это список текстов с историями ребят, которые учились на Хекслете, а потом стали разработчиками.

Когда вы нажимаете на ссылку «Истории успеха», на наш сервер уходит запрос. В нём содержится просьба показать вам список текстов. Это очень похоже на просьбу продать вам бутерброд с индейкой. Это контроллер.

На сервере Хекслета ваш запрос обрабатывается. Программа достаёт из базы данных все последние тексты из рубрики «Истории успеха», чтобы показать список. Это можно сравнить с кухней и поварами из примера с сэндвичем. Это модель.

Сервер Хекслета берёт нужные ингредиенты из базы данных и готовит ваш заказ: список текстов. Тем же занимались повара на кухне магазина сэндвичей. Это снова представление или view.

Изучайте фронтенд- и бэкенд-разработку на JavaScript
На Хекслете есть профессии «Фронтенд-программист» и «Node. js-программист». В процессе обучения на этих профессиях вы научитесь программировать на JavaScript, изучите современные инструменты для разработки фронтенд- и бэкенд-приложений, включая React, Redux, Express.js, Koa, PostgreSQL. Первые курсы в профессиях доступны бесплатно.

Паттерн MVC в реальной веб-разработке: как работает контроллер

Контроллер обрабатывает входящие запросы. Во фреймворке это может заключаться в определении конкретных URL, на которые попадает пользователь при переходе по ссылке или при нажатии кнопки. Рассмотрим это на примере сайта, который отдает пользователю список его друзей:

Переход по ссылке website(.)com/profile/ -> 
возвращает profilewebsite(.)com/friends/ -> 
возвращает friendswebsite(.)com/friend={userName}/ -> 
возвращает профиль конкретного друга

Модель

Модель отвечает за данные, которые хранятся и обрабатываются на сервере.

User: { userName: { firstName, lastName }, friends }

Представление

Это HTML-шаблон, который возвращает сервер после обработки запроса. Если запрос корректно обрабатывается, вы получаете веб-страницу со списком друзей. Если запрос некорректный, вы попадаете на страницу ошибки 404.

<ul>  
  <li>Friend 1: {friendList[0].userName}</li>  
  <li>Friend 2: {friendList[1].userName}</li>  
  <li>Friend 3: {friendList[2].userName}</li>  
  ...
</ul>

Заключение

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

Это адаптированный перевод статьи What is MVC, and how is it like a sandwich shop?

Никогда не останавливайтесь:
В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях

Архитектурный паттерн MVC — JavaScript — Дока

Designing is fundamentally about taking things apart. .. in such a way that they can be put back together. So separating things into things that can be composed that’s what design is.

— Rich Hickey Design. Composition and Performance

Когда мы пишем сложные приложения, нам нужно выполнять различные операции, иногда совершенно друг на друга не похожие:

  • обновить данные на сервере;
  • показать всплывающее окно после клика пользователя;
  • валидировать данные из формы;
  • загрузить дополнительные ресурсы, картинки, скрипты;
  • вызвать стороннее API и обработать ответ.

Считается хорошим тоном делить отличающийся код на модули, которые отвечают за свои конкретные задачи. Как именно разделить код на модули, по каким критериям и принципам — на эти вопросы старается ответить паттерн MVC.

🏛

Это статья из цикла об архитектуре и шаблонах проектирования. Их необходимость и пользу мы рассматриваем в первой статье из цикла. В этой и других статьях — рассматриваем каждый подход отдельно.

Кратко

Секция статьи «Кратко»

MVC (сокращение от Model—View—Controller) — это архитектурный паттерн, который делит модули на три группы:

  • модель (model),
  • представление (view),
  • контроллер (controller).

Модель содержит данные приложения, за которыми приходит пользователь. Например, список своих заказов в интернет-магазине.

Представление показывает эти данные в понятном для пользователя виде. Например, на свёрстанной странице сайта или в приложении на телефоне.

Контроллеры принимают пользовательские команды и преобразуют данные по этим командам. Например, если пользователь нажимает кнопку «Удалить заказ», то контроллер отмечает этот заказ в модели удалённым.

Компоненты архитектуры

Секция статьи «Компоненты архитектуры»

В архитектуре MVC пользователь взаимодействует только с представлением — чаще всего это UI.

🧑‍💻

Есть приложения, где представлением может быть голосовой или жестовый интерфейс, но в веб-разработке чаще всего представление — это графический пользовательский интерфейс, GUI.

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

💡

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

Представим, что мы хотим написать приложение-фонарик. У него будет два состояния: включён и выключен. Состояния будут переключаться кнопкой «On/Off». Также у него будут кнопки включения дневного и ночного света, которые будут менять цвет лампочки на синий и жёлтый соответственно.

Попробуем написать его, используя паттерн MVC.

Модель

Секция статьи «Модель»

Модель содержит данные приложения. Это самый независимый компонент архитектуры, именно от модели зависит, что будет показывать представление, и как будет работать контроллер.

🐕

Концептуально модель похожа на домен из трёхслойной архитектуры.

В модели мы будем держать состояние фонарика. По умолчанию мы его выключим:

const flashLightModel = {  isOn: false,  color: "blue",}
          const flashLightModel = {
  isOn: false,
  color: "blue",
}

Когда пользователь включит фонарик, поле isOn должно будет принять значение true, за это будет отвечать контроллер. Поле color содержит, каким цветом фонарик будет гореть.

Контроллер

Секция статьи «Контроллер»

Контроллер принимает команды от пользователя и преобразует данные в модели согласно этим командам. В нашем приложении контроллер будет содержать функцию для переключения состояния фонарика:

const flashLightController = {  toggle() {    flashLightModel.isOn = !flashLightModel.isOn  },}
          const flashLightController = {
  toggle() {
    flashLightModel.isOn = !flashLightModel. isOn
  },
}

Контроллер может принимать и обрабатывать данные от представления. Например, мы можем переключать цвет специальными кнопками, тогда контроллер проверит, какую кнопку нажали, чтобы включить нужный цвет:

const flashLightController = {  // Остальной код  selectColor(e) {    const buttonName = e.target.name    const buttonColors = {      daylight: "blue",      nightlight: "yellow",    }    const preferredColor = buttonColors[buttonName]    flashLightModel.color = preferredColor  },}
          const flashLightController = {
  // Остальной код
  selectColor(e) {
    const buttonName = e.target.name
    const buttonColors = {
      daylight: "blue",
      nightlight: "yellow",
    }
    const preferredColor = buttonColors[buttonName]
    flashLightModel.color = preferredColor
  },
}

В примере выше контроллер проверяет, кнопку какого цвета нажали: дневного или ночного. В зависимости от нажатой кнопки он выбирает нужный цвет.

Представление

Секция статьи «Представление»

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

<div></div><button type="button" name="power">Включить</button><button type="button" name="daylight">Дневной свет</button><button type="button" name="nightlight">Ночной свет</button>
          <div></div>
<button type="button" name="power">Включить</button>
<button type="button" name="daylight">Дневной свет</button>
<button type="button" name="nightlight">Ночной свет</button>

Кроме разметки в представление также можно отнести код, который управляет отображением фонарика:

const flashLightView = {  redraw() {    const { isOn, color } = flashLightModel    const flash = document.querySelector(".flashlight")    flash.classList.add(`has-color-${color}`)    if (isOn) {      flash.classList.add("is-on")    }  },}flashLightView. redraw()
          const flashLightView = {
  redraw() {
    const { isOn, color } = flashLightModel
    const flash = document.querySelector(".flashlight")
    flash.classList.add(`has-color-${color}`)
    if (isOn) {
      flash.classList.add("is-on")
    }
  },
}
flashLightView.redraw()

А также — код для обработки событий, которые представление будет отдавать контроллеру:

const flashLightView = {  // Остальной код  initEvents() {    const powerButton = document.querySelector(`[name="power"]`)    powerButton.addEventListener("click", () => flashLightController.toggle())    // Код для событий других кнопок  },}
          const flashLightView = {
  // Остальной код
  initEvents() {
    const powerButton = document.querySelector(`[name="power"]`)
    powerButton.addEventListener("click", () => flashLightController.toggle())
    // Код для событий других кнопок
  },
}

Взаимодействие компонентов

Секция статьи «Взаимодействие компонентов»

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

Поток данных

Секция статьи «Поток данных»

В классическом MVC стандартом считается, когда данные:

  • от пользователя передаются представлению;
  • от представления — контроллеру;
  • через контроллер обновляется модель;
  • модель уведомляет представление о том, что что-то изменилось.

✈️

Это называется однонаправленным потоком данных.

Иногда допускается, что компоненты могут общаться напрямую с другими компонентами не по этой схеме, но мы всё же рекомендуем не отходить от канона.

Представление или контроллер?

Секция статьи «Представление или контроллер?»

В MVC часто возникает вопрос, к чему отнести какой-то код: к представлению или контроллеру. В нашем примере выше даже есть такие места.

const flashLightView = {  // ...  initEvents() {    const powerButton = document.querySelector(`[name="power"]`)    powerButton.addEventListener("click", () => flashLightController.toggle())  },}
          const flashLightView = {
  // . ..
  initEvents() {
    const powerButton = document.querySelector(`[name="power"]`)
    powerButton.addEventListener("click", () => flashLightController.toggle())
  },
}

Метод initEvents в представлении может относиться и к контроллеру, если мы решим, что централизованная обработка событий конкретных элементов — это задача контроллера.

Так же с методом selectColor в контроллере:

const flashLightController = {  // Остальной код  selectColor(e) {    const buttonName = e.target.name    const buttonColors = {      daylight: "blue",      nightlight: "yellow",    }    const preferredColor = buttonColors[buttonName]    flashLightModel.color = preferredColor  },}
          const flashLightController = {
  // Остальной код
  selectColor(e) {
    const buttonName = e.target.name
    const buttonColors = {
      daylight: "blue",
      nightlight: "yellow",
    }
    const preferredColor = buttonColors[buttonName]
    flashLightModel. color = preferredColor
  },
}

Если мы решаем, что обработка событий — это задача представления, то мы можем отнести функцию выбора цвета в представление, а в контроллере оставить лишь метод для изменения цвета:

const flashLightController = {  updateColor(color) {    flashLightModel.color = color  },}
          const flashLightController = {
  updateColor(color) {
    flashLightModel.color = color
  },
}

Так как MVC позволяет пользователю обращаться напрямую к контроллеру, то конкретных правил здесь нет, только рекомендации:

  • Стоит использовать последовательные правила для контроллера, модели и представления во всём проекте.
  • Если правила нарушаются специально, это стоит зафиксировать в документации вместе с причиной.
  • Правила стоит выводить из зон ответственности каждого компонента, которые стоит определить заранее.

Как много должен знать контроллер?

Секция статьи «Как много должен знать контроллер?»

Другой подобный вопрос, который возникает при работе с MVC — какая зона ответственности у контроллера, где она заканчивается.

🎛

Контроллер, который умеет больше, называется толстым. Тот, который умеет меньше — тонким.

При тонком контроллере знание о том, как преобразовывать данные, находится в модели. Это не всегда полезно, потому что может замусорить код модели, но иногда оправданно. Например, если мы не хотим «размазывать» это знание по нескольким компонентам.

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

Похожие паттерны

Секция статьи «Похожие паттерны»

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

🍩

В этой статье мы приводим краткое описание паттерна MVC и его вариаций. Чтобы лучше понять разницу между ними, советуем прочесть статью «MVC and its alternatives».

Model—View—Viewmodel

Секция статьи «Model—View—Viewmodel»

В MVVM (сокращение от Model—View—Viewmodel) вместо контроллера используется Viewmodel. Это «надстройка» над представлением, которая связывает данные и представление так, что разработчикам больше не нужно писать самим логику обновления UI и обработки команд пользователя.

Для работы связывания нужен Binder (биндер) — фреймворк, библиотека или целый язык, который автоматически отображает изменения из модели в UI.

👾

Svelte в какой-то степени можно называть биндером, так как он сам занимается связыванием модели и отображения.

Model-View-Presenter

Секция статьи «Model-View-Presenter»

В MVP (сокращение от Model-View-Presenter) место контроллера занимает презентер.

Главное отличие от MVC в том, как расположены компоненты и, соответственно, как передаются данные. Если в MVC данные передавались по кругу, то в MVP компоненты располагаются по линии. На концах находятся модель и представление, а между ними — презентер.

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

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

Плюс такого подхода в том, что не возникает вопросов, какой код к чему относится. Минус — в том, что презентер быстро становится большим и сложным. Приходится разбивать его на модули поменьше, вероятно, добавлять дополнительные «слои».

MVC — Глоссарий веб-документов MDN: Определения веб-терминов

MVC (модель-представление-контроллер) — это шаблон в разработке программного обеспечения, обычно используемый для реализации пользовательских интерфейсов, данных и управляющей логики. Он подчеркивает разделение между бизнес-логикой программного обеспечения и отображением. Это «разделение обязанностей» обеспечивает лучшее разделение труда и улучшение технического обслуживания. Некоторые другие шаблоны проектирования основаны на MVC, например MVVM (Model-View-Viewmodel), MVP (Model-View-Presenter) и MVW (Model-View-Whatever).

Три части шаблона проектирования программного обеспечения MVC можно описать следующим образом:

  1. Модель: управляет данными и бизнес-логикой.
  2. Вид: управляет компоновкой и отображением.
  3. Контроллер: Направляет команды к модели и частям вида.

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

Модель

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

Возвращаясь к нашему приложению списка покупок, модель должна указать, какие данные должны содержать элементы списка — товар, цена и т. д. — и какие элементы списка уже присутствуют.

Вид

Представление определяет способ отображения данных приложения.

В нашем приложении со списком покупок представление будет определять способ представления списка пользователю и получать данные для отображения от модели.

Контроллер

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

Так, например, наш список покупок может иметь формы ввода и кнопки, которые позволяют нам добавлять или удалять элементы. Эти действия требуют обновления модели, поэтому входные данные отправляются контроллеру, который затем соответствующим образом манипулирует моделью, которая затем отправляет обновленные данные в представление.

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

Будучи веб-разработчиком, этот шаблон, вероятно, будет вам хорошо знаком, даже если вы никогда сознательно не использовали его раньше. Ваша модель данных, вероятно, содержится в какой-либо базе данных (будь то традиционная база данных на стороне сервера, такая как MySQL, или решение на стороне клиента, такое как IndexedDB [en-US].) Управляющий код вашего приложения, вероятно, написан на HTML/JavaScript. , и ваш пользовательский интерфейс, вероятно, написан с использованием HTML/CSS или чего-то еще, что вам нравится. Это очень похоже на MVC, но MVC заставляет эти компоненты следовать более строгому шаблону.

На заре Интернета архитектура MVC в основном реализовывалась на стороне сервера, когда клиент запрашивал обновления через формы или ссылки и получал обновленные представления для отображения в браузере. Однако в наши дни большая часть логики передается клиенту с появлением хранилищ данных на стороне клиента и XMLHttpRequest, позволяющего по мере необходимости обновлять частичные страницы.

Веб-фреймворки, такие как AngularJS и Ember.js, реализуют архитектуру MVC, хотя и немного по-разному.

  • Модель-представление-контроллер в Википедии

Последнее изменение: , участниками MDN

Что такое, архитектура и пример

Мэтью Мартин

Часов

Обновлено

Что такое MVC Framework?

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

В этом руководстве по MVC вы узнаете больше об основах MVC.

  • История MVC
  • Особенности MVC
  • Архитектура MVC
  • Примеры MVC
  • Популярные веб-фреймворки MVC
  • Преимущества MVC: основные преимущества
  • Недостатки использования MVC
  • Трехуровневая архитектура и архитектура MVC

История MVC

  • Архитектура MVC впервые обсуждалась в 1979 Трюгве Реенскауг
  • Модель

  • MVC была впервые представлена ​​в 1987 году в языке программирования Smalltalk.
  • MVC впервые был принят в качестве общей концепции в статье
  • 1988 года.

  • В последнее время шаблон MVC широко используется в современных веб-приложениях

Особенности MVC

  • Простая проверка без трения. Хорошо тестируемый, расширяемый и подключаемый фреймворк
  • Для разработки архитектуры веб-приложения с использованием шаблона MVC он предлагает полный контроль над вашим HTML, а также вашими URL-адресами
  • Использовать существующие функции, предоставляемые ASP. NET, JSP, Django и т. д.
  • Четкое разделение логики: Модель, Представление, Контроллер. Разделение прикладных задач, т.е. бизнес-логика, логика Ul и логика ввода
  • Маршрутизация URL-адресов для SEO-дружественных URL-адресов. Мощное сопоставление URL-адресов для понятных и доступных для поиска URL-адресов
  • Поддержка разработки через тестирование (TDD)

Архитектура MVC

Вот подробная архитектура инфраструктуры MVC:

Схема архитектуры MVC

Три важных компонента MVC:

  • Модель: включает все данные и связанную с ними логику
  • Представление: представление данных пользователю или обработка взаимодействия с пользователем
  • Контроллер: интерфейс между компонентами модели и представления

Давайте подробно рассмотрим этот компонент:

Представление

Представление — это та часть приложения, которая представляет представление данных.

Представления создаются на основе данных, собранных из данных модели. Представление запрашивает у модели информацию, чтобы она представляла выходное представление пользователю.

Представление также представляет данные из диаграмм, диаграмм и таблиц. Например, любое представление клиента будет включать в себя все компоненты пользовательского интерфейса, такие как текстовые поля, раскрывающиеся списки и т. д.

Контроллер

Контроллер — это часть приложения, которая обрабатывает взаимодействие с пользователем. Контроллер интерпретирует ввод данных пользователем с помощью мыши и клавиатуры, информируя модель и представление о необходимых изменениях.

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

Модель

Компонент модели хранит данные и связанную с ними логику. Он представляет данные, которые передаются между компонентами контроллера или любой другой связанной бизнес-логикой. Например, объект Controller будет извлекать информацию о клиенте из базы данных. Он манипулирует данными и отправляет обратно в базу данных или использует их для отображения тех же данных.

Он отвечает на запрос представлений, а также отвечает на инструкции контроллера по обновлению. Это также самый нижний уровень шаблона, который отвечает за сохранение данных.

Примеры MVC

Давайте посмотрим пример Model View Controller из повседневной жизни:

Пример 1:

  • Предположим, вы идете в ресторан. Вы не пойдете на кухню и не приготовите еду, которую наверняка сможете приготовить дома. Вместо этого вы идете туда и ждете, пока подойдет официант.
  • Сейчас к вам подходит официант, и вы заказываете еду. Официант не знает, кто вы и что вы хотите, он просто записал детали вашего заказа на еду.
  • Затем официант идет на кухню. На кухне официант не готовит еду.
  • Повар готовит вам еду. Официанту передается ваш заказ вместе с номером вашего столика.
  • Повар приготовил для вас еду. Он использует ингредиенты для приготовления пищи. Предположим, вы заказываете сэндвич с овощами. Затем ему нужны хлеб, помидоры, картофель, стручковый перец, лук, биточки, сыр и т. д., которые он достает из холодильника
  • .

  • Повар передал еду официанту. Теперь работа официанта заключается в том, чтобы вынести эту еду за пределы кухни.
  • Теперь официант знает, какие блюда вы заказали и как они поданы.

В этом примере архитектуры MVC

 View = You
Официант = Контроллер
Кук = Модель
Холодильник = Данные
 

Давайте посмотрим еще один пример модели MVC,

Пример 2:

Механизм привода автомобиля является еще одним примером модели MVC.

  • Каждый автомобиль состоит из трех основных частей.
  • Вид= Пользовательский интерфейс: (Рычаг переключения передач, панели, рулевое колесо, тормоз и т. д.)
  • Контроллер-механизм (двигатель)
  • Модель

  • – Хранение (бак для бензина или дизельного топлива)

Автомобиль работает от двигателя, берет топливо из хранилища, но работает только с использованием указанных устройств пользовательского интерфейса.

Популярные веб-фреймворки MVC

Вот список некоторых популярных фреймворков MVC:

  • Ruby on Rails
  • Джанго
  • ТортPHP
  • Yii
  • CherryPy
  • Весна МВК
  • Катализатор
  • Рельсы
  • Zend Framework
  • CodeIgniter
  • Ларавель
  • Топливо PHP
  • Симфония

Преимущества MVC: Основные преимущества

Вот основные преимущества использования архитектуры MVC:

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

  • MVC позволяет логически группировать связанные действия на контроллере вместе.

Недостатки использования MVC

  • Сложность чтения, изменения, модульного тестирования и повторного использования этой модели
  • Навигация по фреймворку иногда может быть сложной, поскольку она вводит новые уровни абстракции, которые требуют от пользователей адаптации к критериям декомпозиции MVC.
  • Нет формальной поддержки проверки
  • Повышенная сложность и неэффективность данных
  • Сложность использования MVC с современным пользовательским интерфейсом
  • Для параллельного программирования требуется несколько программистов.
  • Требуется знание нескольких технологий.
  • Обслуживание множества кодов в контроллере

Трехуровневая архитектура и архитектура MVC

Параметр Трехуровневая архитектура Архитектура MVC
Связь Этот тип шаблона архитектуры никогда не связывается напрямую с уровнем данных. Все уровни взаимодействуют напрямую, используя треугольную топологию.
Использование 3 уровня: широко используется в веб-приложениях, где клиент, уровни данных и промежуточное ПО работают на физически отдельных платформах. Обычно используется в приложениях, работающих на одной графической рабочей станции.

Сводка

  • MVC — это архитектурный шаблон, который разделяет приложение на 1) модель, 2) представление и 3) контроллер
  • Модель: включает все данные и связанную с ними логику
  • Представление: представление данных пользователю или обработка взаимодействия с пользователем
  • Контроллер: интерфейс между компонентами модели и представления
  • Архитектура MVC была впервые обсуждена в 1979 году Трюгве Реенскаугом
  • .

    This entry was posted in Популярное