Поясніть контролер перегляду моделі

Мій досвід розробки динамічних веб-сайтів здебільшого обмежений 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 Architecture - це спосіб організувати робочий процес всередині системи sotfware, продумати це як шаруватий спосіб впровадження системної поведінки. Це шари:

1. Модель : представляє вашу модель даних, її системне ядро, де повинна бути локалізована вся інформація, що стосується неї. Так, наприклад: якщо ви збираєтеся розіграти гру, вам знадобляться гравці, правила, перешкоди та певна логіка, пов'язана з взаємодією таких елементів, як-от: Гравці повинні мати можливість сортувати перешкоди, коли застосовується певний набір правил.

   Модель є першим думаю , що ви повинні думати геть , бо його буде центром ваших додатків .

2. Контролер : саме тут відбувається магія і там, коли багатошарова архітектура відповідає об'єктно-орієнтованій парадигмі, яку вона мала використовувати. Ось де ви реалізуєте, як реагує система, коли якийсь користувач програми запитує щось про програму і користувальницький інтерфейс.

   Контролер повинен мати можливість обробляти об'єкти моделі, робити операції з ними, щоб досягти того, що просив користувач, а потім делегувати результат відповідному шару перегляду, щоб повернути його нашому користувачеві.

3. Перегляд : це початкова та кінцева точка взаємодії користувачів. Тут ви визначаєте, як користувачі взаємодіють із програмою. У наш час досить поширені користувачі намагаються отримати доступ, наприклад, до веб-додатків з різних видів ЗМІ, таких як: Мобільні телефони, Столи, ПК, Ноутбуки тощо.

   Як правило, кожна технологія для створення представлення потребує іншої мови, тому уявіть, що ваша модель даних та спосіб взаємодії моделі та як ви реалізуєте ці взаємодії є жорстким кодом, абсолютно не існує способу повторного використання коду таким чином, який не є CopyPaste . Результат - код, який пахне і витрачається багато часу на адаптацію системи HOLE.

   Вірусність перегляду в окремому шарі дозволяє нам працювати незалежно від моделі, над якою ми працюємо в даний час . Нам потрібно лише знати, як нам надавати список об'єктів, які нам надсилає контролер. Як він його генерував, абсолютно тривіально

Отже, нарешті ми отримали незалежну модель , яку можна пристосувати відповідно до наших сучасних потреб (сьогодні мені потрібно керувати грою Monouser без правил, завтра я хочу грати з друзями, а тепер її мультикористувачем тощо) це не залежить від того, як ми будемо надавати це користувачеві. Потім контролер, який фіксує запит користувачів, що надійшли з подання, обробляє об'єкти моделі, а потім повертає інформацію до подання, щоб надати її.

Повернення до першого питання, яке ви задали: Як ви бачите (сподіваюся), MVC - це СПОСІБ робити речі, а не ТЕХНОЛОГІЯ для створення програмного забезпечення. Ви можете використовувати сервіси java та впроваджувати архітектуру MVC під нею.

Ось приклад веб-сайту Q&A, який використовує архітектуру MVC, щоб трохи уточнити

Щоб відповісти на ваше запитання

What does MVC offer over something like a Java servlet

MVC - це модель, а не технологія. Тож шаблон можна застосувати і при програмуванні із сервлетами.

Дозвольте спробувати пояснити шаблон MVC із сервлетами. Отже, те, що ви намагаєтеся зробити, коли ви говорите про застосування MVC, це розділити модель (бізнес-логіка), вид (логіка презентації) та контролер (контролер Servlet, який делегує управління відповідної бізнес-логіці).

У цьому випадку MVC - це не просто відокремлення бізнесу від шару презентації та рівня контролера, але бізнес-рівень навіть не знає, що існує контролер або презентація.

Основні рамки на Java, такі як Struts, слідують цій схемі. Я думаю, що ви зрозуміли неправильну концепцію. Більше про це можна прочитати в Інтернеті.

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

• Модель : Ваші дані (не виключно ваша база даних! Модель може навіть бути файлом ini або xml або даними веб-служби). Класи моделей служать для визначення, збирання та обробки даних. Прочитайте чудову статтю під назвою " The M in MVC: Чому моделі неправильно зрозуміли та не оцінювали ". Доступ до моделі повинен мати лише контролер.
• Перегляди : Ваш GUI (презентаційний) код. Має доступ лише до контролера
• Контролер : Ваша логіка. Обробляє зв'язок між моделлю та поданням.

Концепція Model-View-Controller - це не нове. Це почалося з Smalltalk близько 1979 року.

По суті, MVC - це спосіб організувати обов'язки свого коду таким чином, щоб він був модульним, передбачуваним та надійним.

Поділ дозволяє вам отримати наступні свободи:

• Можливість еволюціонувати в моделі, не впливаючи на логіку програми або відображаючи дані
• Можливість змінити логіку бізнесу, не впливаючи на модель (тобто додавати нові кроки тощо)
• Можливість представити модель у декількох різних способах

З обережністю ви потенційно можете спроектувати модель та контролер, щоб ви могли повністю замінити настільний додаток веб-додатком у якості переднього кінця.

Зовсім недавно підхід Ruby on Rails до MVC представив новіші концепції, які були скопійовані майже у всі рамки веб-додатків у стилі MVC. Сюди входили поняття "Конвенція про конфігурацію", відображення дій контролера до методів класів та маршрутизація запитів URL до базового коду.