Объяснить модель представления контроллера

Мой опыт разработки динамических веб-сайтов ограничен в основном сервлетами Java. Я использовал Tomcat для разработки различных Java-сервлетов, и я без колебаний скажу, что я достаточно хорошо владею этой технологией, а также клиентским HTML / CSS / Javascript для внешнего интерфейса.

Когда я думаю о «динамическом веб-сайте», я думаю: пользователь запрашивает URL со строкой запроса, сервер получает запрос, а затем продолжает динамически выводить HTML, чтобы ответить на запрос. Это часто включает в себя связь с базой данных, чтобы получить запрошенные данные для отображения. Это в основном идея doGetметода Java HttpServlet.

Но в наши дни я все больше слышу о новых фреймворках, таких как Django и Ruby on Rails, которые используют преимущества архитектуры «Model View Controller». Я читал различные статьи, которые объясняют MVC, но у меня возникают проблемы с пониманием преимуществ. Я понимаю, что общая идея состоит в том, чтобы отделить бизнес-логику от логики пользовательского интерфейса, но я не вижу, чем это действительно отличается от обычного веб-программирования. Веб-программирование по своей природе заставляет вас отделять бизнес-логику (внутреннее программирование на стороне сервера) от программирования пользовательского интерфейса (клиентский HTML или Javascript), потому что они существуют в совершенно разных сферах программирования.

Вопрос: Что предлагает MVC над чем-то вроде сервлета Java, и, что более важно, что такое MVC и чем он отличается от того, что вы обычно делаете для разработки динамического веб-сайта с использованием более традиционного подхода, такого как сервлет Java (или даже что-то старшее вроде CGI)? Если возможно, при объяснении MVC, приведите пример, который иллюстрирует, как MVC применяется к процессу веб-разработки и как это выгодно.

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

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

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

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

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

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

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

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

   Virtude иметь в виде в отделенной слое, позволяет работать независимо от модели мы в настоящее время работаем над . Нам нужно только знать, как мы должны отображать список объектов, которые нам отправляет контроллер. Как он породил это совершенно тривиально

Итак, наконец, мы получили независимую модель, которую можно адаптировать по своему усмотрению в соответствии с нашими текущими потребностями (сегодня мне нужно работать с игрой Monouser без правил, завтра я буду играть с друзьями, а теперь с ее многопользовательским режимом и т. Д.) это не зависит от того, как мы собираемся представить его пользователю. Затем контроллер, который захватывает пользовательский запрос, поступивший из представления, обрабатывает объекты модели, а затем передает информацию в представление для ее отображения.

Вернемся к первому вопросу, который вы задали: как вы можете видеть (я надеюсь), MVC - это ПУТЬ, чтобы делать вещи, а не ТЕХНОЛОГИЯ для создания программного обеспечения. Вы можете использовать свои Java-сервлеты и реализовать под ним MVC-архитектуру.

Вот пример сайта Q & A, использующего архитектуру MVC, чтобы прояснить немного

Ответить на ваш вопрос

What does MVC offer over something like a Java servlet

MVC - это шаблон, а не технология. Таким образом, шаблон можно применять и при программировании с помощью сервлетов.

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

В этом случае MVC не просто отделяет бизнес от уровня представления и уровня контроллера, но бизнес-уровень даже не знает о существовании контроллера или представления.

Основные структуры в Java, такие как Struts, следуют этому шаблону. Я думаю, что вы поняли концепцию неправильно. Вы можете узнать больше об этом в Интернете.

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

• Модель : ваши данные (не только ваша база данных! Модель может быть даже файлом ini или xml или данными из веб-службы). Классы моделей служат для определения, сборки и обработки данных. Прочитайте отличную статью « M в MVC: почему модели неправильно понимают и не ценят ». Модель должна быть доступна только для контроллера.
• Просмотры : Ваш код GUI (презентации). Доступ только к контроллеру
• Контроллер : Твоя логика. Управляет связью между моделью и представлением.

Концепция Model-View-Controller не является чем-то новым. Это началось с Smalltalk около 1979 года.

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

Разделение позволяет вам следующие свободы:

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

С осторожностью вы можете спроектировать модель и контроллер, чтобы полностью заменить настольное приложение веб-приложением в качестве внешнего интерфейса.

Совсем недавно в подходе Ruby on Rails к MVC были представлены некоторые новые концепции, которые были скопированы практически во все фреймворки веб-приложений в стиле MVC. Это включает в себя понятия «Соглашение о конфигурации», сопоставление действий контроллера с методами классов и маршрутизацию запросов URL-адресов к базовому коду.