Поясніть MVC непрограмістам [закрито]


31

У мене є потреба пояснити MVC непрограмістам. А саме керівникам інших департаментів у контексті звіту про хід. Одна з речей, яку я роблю, - це рефакторинг нашої кодової бази на поділ MVC.

Що таке MVC-розділення вони можуть запитати? Чому це потрібно запитати?

Прочитавши досить технічну відповідь, як це: Що насправді MVC? , Я не зовсім задоволений, оскільки буду спілкуватися з непрограмістами. Вони можуть кивати головою, але, напевно, не зрозуміють, що це таке і навіщо це потрібно.

Насправді я не цілком розумію, що таке MVC, крім "поділу проблем, обов'язків, функцій, класів, блоків, завдань, речей з метою підвищення гнучкості внесення змін до програмного забезпечення". Відокремлення бази даних від подання та погляду від ділової логіки з використанням таких методів, як інструменти та методи DI та OO - це те, що я вважаю поділом MVC.

Тож наступного разу, коли ви пояснюєте MVC непрограмісту, який, наприклад, має досвід продажів та бухгалтерського обліку, що б ви їм сказали?


3
рекомендовано прочитати: Як пояснити $ {щось} до $ {когось}?
гнат

12
Заявіть, що це "Найкраща практика", і вони будуть раді.
Йоган

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

2
Як ви збираєтесь пояснити, якщо ви не до кінця зрозумієте, що це?
BЈоviћ

Я думаю, що, мабуть, слід зробити аналогію зі зміною деталей аспекту промислової революції ... безумовно, вони можуть зрозуміти переваги того, що можна просвердлити і простукувати 1 / 4-20 отвір, не турбуючись про те, чи ні підійде болт.
J ...

Відповіді:


70

Ви не пояснюєте MVC.

Що ви робите, це пояснити, що це реструктуризація бази даних.

Реструктуризація, яка спрощує базу даних коду, а отже, дозволяє розробникам вносити швидші та кращі зміни у звіти про помилки та запити на функції, з меншими помилками.

Їм не потрібно знати технічні деталі, тільки чому це було зроблено, що було досягнуто завдяки цьому та як користь для бізнесу.

Іншими словами - говоріть їм свою мову.


13
IOW поясніть необхідність реструктуризації до MVC (це чудово: розмовляйте їм своєю мовою )
Вовк

4
Часто корисно згадати випадки, коли виправлення помилок та запити на функції були б швидшими (дешевшими), якби база даних коду мала відповідний розгляд проблем.
Ерік Вілсон

14
Я думаю, що було б корисно зробити наступний стрибок і підказати, що мова, якою говорять, - £ £ ¥ € ƒrub. Якщо ви пояснюєте це непрограмісту, це, мабуть, у діловому контексті, і дуже ймовірно, що воно зводиться до "куди йдуть гроші"?
Джоель Етертон

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

41

Хоча я схвалюю суть відповіді Одеда , що ви повинні пояснювати технічні проекти менеджерам підприємств "їхньою мовою", я маю сумнів щодо "їм не потрібно знати технічні деталі, тільки чому це було зроблено".

Якщо ви переглядаєте проект чи інвестиційний розгляд із керівниками відділів, і заявляєте, що "ми це робимо", вони можуть запитати "Умм ... чому? Це здається великим вкладенням часу та енергії. Чи можете ви дати нам трохи більше розуміння, що ви робите і чому? " Це здається надзвичайно розумним питанням. Ви не хочете, щоб вас спіймали в позиції "Ну ... це складно". або "Ні, я не можу реально пояснити це". або "Не переживайте про це". Чим старший персонал, для якого ви робите огляд проекту, тим менше шансів на те, щоб вони летіли "це просто речі, які я не можу пояснити". Краще, якщо ви зможете піти хоча б на один рівень глибше, щоб інші відчували себе комфортно, щоб 1) ви знали, що ви '

Отже, майте ескіз MVC у кишені стегна, готовий до роботи. Щось на зразок:

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

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


4
So, have a sketch of MVC in your hip pocket, ready to go.- чи, можливо, pp Презентація ;-) щодо користувача "їхня мова"?
Вовк

Я б не сказав, що "моделі відповідають за основні дані та логіку бізнесу". Логіку бізнесу найкраще тримати окремо у власному шарі. Насправді, моделі - це лише сукупність даних, що передаються від контролера до перегляду, щоб роз’єднати ці два шари. Наприклад, ви майже ніколи не передаєте жодний об'єкт ORM для перегляду, а їх набір, а також деякі інші різні дані. Дивіться мою відповідь для більш тривалого пояснення.
Тобія

2
@Tobia Саме так Microsoft називає модель. "Модель" - це презентаційно-агностична комп'ютерна модель системи, з якою користувач взаємодіє, тому майже все, що не є частиною перегляду та контролера.
Доваль

@Doval Це може бути інтерпретація Microsoft, але це обмеження загальності MVC. Погляньте на спритні рамки MVC, такі як Ruby on Rails, Django або Grails, щоб побачити, що я маю на увазі. Я ще більше розширив свою відповідь, щоб висвітлити це поширене непорозуміння.
Тобія

3
У оригінальній схемі MVC Smalltalk кожен елемент керування на екрані мав власну модель, вигляд та контролер. Не будемо робити вигляд, що існує єдине визначення MVC, з яким всі згодні. На щастя, йому потрібно лише пояснити, що він робить.
RemcoGerlich

9

з метою підвищення гнучкості внесення змін до програмного забезпечення

Менеджери зацікавлені в кінцевому результаті. Чим менше технічних вони, тим менше шансів, що вони переймаються тим, як ви туди потрапите. MVC дуже поширений, популярний і перевірений.

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

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

Це все буде дуже складно, якщо в цьому конкретному проекті буде багато нагальних питань. Вони можуть не хотіти зробити крок назад, тому ви можете зробити два кроки вперед. На вирішення може бути чекати або реалізовувати меншими шматками.


9
  • Модель - Провід / електрика
  • Вид - світильник
  • Контролер - вимикач світла

Відносно легко вимикати компоненти (світильник, вимикач / диммер). Можливо, не так багато електропроводки, але все-таки це можна зробити, не впливаючи на інші компоненти. Кожен повинен мати можливість уявити це у своїй голові, навіть маркетингові / продажні типи. (Чітке розділення тощо)

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

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


Гммм ... ця аналогія насправді не "потрапила на місце" ІМХО.
DevSolar

Але вся ідея про надання якихось аналогій саме в цьому. Я б написав щось подібне. Зазвичай щось із залученням автомобілів чи грошей
справляється

Дійсно, люди, які повинні бути головними, - це непрограмісти. Я думаю, що більшість користувачів сайту - це програмісти! :)
Джон Рейнор

3

Самий простий спосіб зрозуміти MVC: модель даних , то точка зору вікно на екрані , і контролер є сполучною ланкою між ними .

Найкраща рубрика коли-небудь: "Нам потрібні SMART-моделі, тонкі контролери та перегляди DUMB"

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

Усі варіанти MVC використовують однаковий розподіл компонентів, але зазвичай вони відрізняються тим, як ці компоненти взаємодіють.

введіть тут опис зображення

Для тих з вас, хто не знає, MVC був спочатку описаний у вигляді дизайну для використання з Smalltalk Тригве Реенскауг у 1979 році . Його робота була опублікована під заголовком "Програмування програм у Smalltalk-80: Як використовувати Model-View-Controller" та проклала основу для більшості майбутніх реалізацій MVC.


3

Я на півдорозі погоджуюся з «Одідом» - навчитися переконувати своїх нетехнічних колег та менеджерів у тому, що те, що ти робиш, важливо і корисно, не пояснюючи прискіпливих деталей, - необхідний навик, який ти би розумно розвивав.

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

Що вбік, давайте відповімо на питання:

Мені корисно використовувати аналогії, які розуміють ділові люди. Для MVC я описую це як бізнес.

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

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

Це, сподіваємось, відповість "що" - "чому" також легко за цією аналогією:

Уявіть собі ідеальну компанію, де кожен відділ відповідає за один набір завдань, і знає, що у неї завжди будуть необхідні ресурси, не турбуючись про те, що роблять інші. Торговий представник знаходить клієнта, отримує їх замовлення, передає його керівництву, яке схвалює, а потім відправляється на склад / виробництво / інженерію для виконання. Зворотній зв'язок прямий - нікому більше не потрібно вступати, якщо не виникає проблема. Це хороший дизайн MVC - у кожній частині є робота, і не потрібно турбуватися про інші частини. Таким чином, це легко змінити, якщо нам потрібно. У дизайні, що не належить до MVC, відповідальність не зрозуміла. Торговий представник може спробувати змінити товар, коли клієнт попросить щось інше. Або вони можуть давати різні ціни залежно від того, як вони почували себе в цей день. Генеральний директор може зійти на заводській підлозі, переплутавшись з виробничою лінією, коли йому слід переживати, як отримати надійнішу ланцюжок поставок. Складські працівники можуть бути на торговому майданчику, розмовляючи з клієнтами, коли вони повинні виконувати замовлення, які вже були прийняті.

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

** Відмова від відповідальності - якщо ваша компанія погано організована, вони можуть цього образити. У такому випадку вам знадобиться ще одна аналогія. Також вам може знадобитися інша робота.


Якщо компанія ОП погано організована, то я пропоную йому поговорити про "розподіл роботи" за
принципом

Хороший опис - відмінна відмова.
Citizenkong

2

Переваги MVC полягають насамперед у розділенні проблем:

Це дозволяє людям сконцентруватися на тому, що вони роблять найкраще.

Database admins develop the model
Programmers write the controllers
and Graphic designers can design the views.

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

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


4
Я б не прирівнював модель MVC до бази даних, а також контролер MVC з введенням користувача.
Тобія

1
@Tobia Так, але нюанси цього втратяться на людині, яка не є технічною. Він отримує крапку
B2K

@Tobia переглянувши це, скоригував опис, щоб бути більш точним. Дякуємо за ваші коментарі.
B2K

1

Я б сказав їм, що MVC розділяє мої проблеми.

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

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

Моє третє занепокоєння - це те, як виглядає сайт - Сторінка, яку вони відвідують, робити те, що вони хочуть.

(Я не хотів би сказати їм цю наступну частину) Отже, для того, мої пояснення були щодо моделі, контролера та перегляду.


1

Поясніть переваги

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

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

Модель

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

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

Ви також можете легко розширити додаток, додавши додаткові моделі, він дуже модульний і чистий.

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

Вид

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

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

Ви також можете створити альтернативні передні торці, які працюють з існуючою системою. Ви можете показувати свої дані як мобільний додаток, API, PDF або електронну таблицю Excel. Це можна зробити, не забиваючи решту системи. Ви менше шансів зламати речі випадково. Ви можете легко створити точки інтеграції для існуючих систем.

Контролер

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

Інші переваги

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

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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.