Чи не MVC anti OOP?

Основна ідея OOP полягає в об'єднанні даних і поведінки в єдине ціле - об'єкт. У процедурному програмуванні є дані та окремо алгоритми, що модифікують дані.

У шаблоні Model-View-Controller дані та логіка / алгоритми розміщуються у різних об'єктах відповідно моделі та контролері. Чи в еквівалентному підході OOP не повинні модель та контролер розміщуватися в одній логічній сутності?

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

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

У MVC бізнес-логіка йде в моделі, а не в контролері. Контролер насправді є лише проміжним з’єднанням, щоб склеїти Погляд та Модель. Тож у моделі ви можете мати дані та поведінку в одному місці.

Але навіть така домовленість не гарантує суворого злиття даних / поведінки. Об'єктами, що містять лише дані, можна керувати іншими класами, що містять лише логіку, і це цілком прийнятне використання OOP.

Наведу конкретний приклад. Це трохи надумано, але скажімо, у вас є Currencyоб'єкт, і цей об’єкт має можливість представляти себе у будь-якій доступній валюті, прив’язаній до долара. Тож у вас були б такі методи, як:

public decimal Yen { get { return // dollars to yen; } }
public decimal Sterling { get { return // dollars to sterling; } }
public decimal Euro { get { return // dollars to euro; } }

... і ця поведінка буде інкапсульована об'єктом валюти.

Але що робити, якщо я хотів перевести валюту з одного рахунку на інший або депозитувати якусь валюту? Чи така поведінка також буде інкапсульована в об'єкт Валюта? Ні, не буде. Гроші у вашому гаманці не можуть перераховуватися з гаманця на ваш банківський рахунок; вам потрібен один чи більше агентів (касир чи банкомат), щоб допомогти отримати гроші на ваш рахунок.

Таким чином, така поведінка буде інкапсульована в Tellerоб'єкт, і вона буде приймати Currencyі Accountоб'єкти як вхідні дані, але вона не міститиме жодних даних, за винятком, можливо, трохи місцевого стану (або, можливо, Transactionоб'єкта), який допоможе обробити вхідні об'єкти.

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

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

OOP не обмежує взаємодію між об'єктами, у яких кожен має свої дані та власну поведінку.

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

OOP також стосується розділення проблем , тобто для розділення різних ролей / відповідальності в різних об'єктах.

MVC розділяється на наступні компоненти:

• Модель: дані та її бізнес-логіка
• Вид: представлення даних
• Контролер: координація між моделлю та видом.

Таким чином, ці обов'язки чітко розрізнені і їх дійсно слід розділити на кілька об'єктів.

У шаблоні Model-View-Controller дані та логіка / алгоритми розміщуються у різних об'єктах відповідно моделі та контролері.

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

Подумайте про це так: якщо об’єкти не зможуть передавати дані туди-сюди, не порушуючи інкапсуляцію, у вас дійсно може бути лише один об’єкт!

Чи в еквівалентному підході OOP не повинні модель та контролер розміщуватися в одній логічній сутності?

MVC - це підхід OOP - конкретно, це рецепт рішення про те, як використовувати об'єкти для ефективної організації програми. І ні , модель і контролер не повинні бути однією сутністю. Контролер дозволяє розділяти між моделлю та видом. Збереження моделі та перегляду незалежно одне від одного робить їх і більш випробуваними, і більш корисними для використання.

MVC - модель, яка описує розумний спосіб взаємодії об'єктів; це сам по собі не метаклас. При цьому ОО полягає в описі поведінки та даних суб'єктів, а також взаємодії цих суб'єктів. Йдеться не про об'єднання всієї системи в один масивний об’єкт.

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

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

Модельний рівень - це не просто дані, а рівень контролера - це лише логіка.

Шар контролера матиме повну колекцію об'єктів для своїх цілей. Будуть об'єкти для отримання вхідних даних із перегляду та перетворення цього вводу у форму, яку модель може обробити. Структура Java Struts має хороший приклад цього у своїй моделі Action / Form. Форма заповнюється користувачем, а потім передається в дію. Дія бере ці дані та використовує їх для маніпулювання моделлю.

Таким же чином, рівень моделі не складається повністю з даних. Наприклад, візьміть об’єкт "Користувач" - вам може знадобитися код, який отримує користувач із бази даних, або код для асоціації користувача з замовленням або для підтвердження того, що адреса користувача знаходиться в межах сфери послуг вашої компанії ... ви отримуєте картина. Це не логіка контролера. Це бізнес-логіка, і багато хто змусив її розділити рівень моделі на кілька шарів, таких як Сервісний або Менеджер-шари для бізнес-логіки, DAO (Об'єкт доступу до бази даних) для доступу до бази даних та інші.

MVC не є методом організації окремих операцій моделі. Він працює на більш високому рівні, ніж це - це метод організації способу доступу до програми. Перегляд призначений для представлення даних та людських дій для їх маніпулювання, Контролер - це переклад між діями користувача та різними поглядами, а Модель - там, де перебувають бізнес-дані та ділові причини їх існування.

Сенс ООП полягає в об'єднанні даних і функціональних можливостей, які належать разом . Розрахунок, який ґрунтується на певній частині даних, не завжди належить до цих даних.

У MVC функціональність для відображення фрагмента даних (подання) зберігається окремо від даних (модель). Чому так? Це спеціально для того, щоб логіку відображення можна було змінити без необхідності зміни базових даних. Це дозволяє легко змінювати представлення даних, коли вам потрібно зробити різну презентацію одних і тих же даних: або коли характеристики апаратного забезпечення дисплея змінюються: або при переході з Windows на Linux; або коли ви хочете, щоб двоє людей мали два різні способи перегляду одних і тих же даних.

MVC не суперечить OOP - він фактично випливає з правильного застосування Об'єктно-орієнтованих принципів.

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

Подібно до того, як модельний об’єкт підтримує дані для встановлення того, які правила ведення бізнесу діють, контролер IMO повинен підтримувати більш загальні дані про стан додатків, що стосуються того, як має поводитись додаток, наприклад, чи користувач увійшов у систему чи має дійсний кредит дані картки на місці. Модельні методи визначають в першу чергу стан цих речей, але має сенс для контролера підтримувати прапори, що стосуються загального потоку додатків, якщо вони не застосовуються до того, як ведеться бізнес або проводяться транзакції даних. Визначивши, що вони не ввійшли в систему, навіть не обтяжуйте модель перевіркими стану користувача, поки не стане зрозумілою ще одна спроба входу.

Так само і з належним об'єктом перегляду порівняно з типовішими шаблонами HTML, які ви бачите в більшості веб-рамок на серверній стороні. Після завантаження кольорових налаштувань користувача, це має бути представлення, яке утримує ці дані та виконує їх. Завантаження, перевірка та зміна налаштувань - це всі проблеми моделі, але вони можуть бути проблемами моделей лише один раз, поки не відбудуться зміни.

ІМО, нічого не говорить про те, що контролери не можуть бути складеними об'єктами з видами та моделями як внутрішні сукупні об'єкти. Це насправді має сенс, якщо ви застосовуєте MVC у меншому масштабі, як заводський віджет UI, оскільки контролер є ідеальним місцем для викриття інтерфейсу до об’єктів додатків вищого рівня, захоплюючи дані та логіку деталей взаємодії перегляду та моделі. Це насправді не має сенсу для монолотичних об’єктів додатків, де контролер справді є об'єктом найвищого рівня.

Як я це розумію; Аргумент - це архітектура, заснована на компонентах та OOP. І не потрапляючи в релігійну війну, я думаю, що вони обидва описують одне і те ж; просто дивлячись на це з різних ракурсів.

Наприклад, вся суть OOP / OOD полягає в тому, щоб зробити ваш код більш модульним і багаторазовим. Так?

Яка саме мета складової архітектури. Тож вони більше схожі на все інше.

Я думаю, що MVC - це лише природна еволюція ООП, і наважуся це сказати; кращий спосіб впорядкувати свої об’єкти, відокремити проблеми та повторно використовувати код.

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

Отже, я думаю, що справжнє питання є; чи ми більш схильні до процесуального коду при використанні шаблону MVC.

(а може, я просто наберу кілька голосів?)

Не проти, але також OOP не потрібен для MVC.

Оскільки контролери, які зазвичай представлені класом, не містять даних. Для яких достатньо було б чистих функцій.

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

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

На мою думку, ООП має недолік, оскільки оскільки (дані та поведінка) формуються як одна сутність (клас), це демонструє більше ефекту сполучення, ніж згуртованості. Тоді як MVC, з іншого боку, має Модель, що містить ... (Beans, DAOs, Інші класи логіки), Контролер, який визначає, яким чином повинен керувати управління, а Views для визначення способу відображення даних подаються відокремлено. Виходячи з цього, незалежно від того, якщо проект занадто великий, щоб підготуватися, його можна легко зробити як окремий суб'єкт, окрім як змішатись на відміну від ООП. Проблема вирішується за логічним малюнком подібно до стратегії поділу n conquer, і MVC слідує цьому якнайменше.