У меня есть необходимость объяснить MVC непрограммистам. А именно, руководителям других отделов, в контексте отчета о проделанной работе. Одна из вещей, которые я делаю, - это рефакторинг нашей кодовой базы в сторону разделения MVC.

Какое разделение MVC они могут спросить? Зачем они могут спросить?

После прочтения довольно технического ответа вроде этого: что такое MVC, на самом деле? Я не совсем доволен, так как буду разговаривать с непрограммистами. Они могут кивать головой, но, вероятно, не поймут, что это и зачем это нужно.

В действительности, я не до конца понимаю, что MVC отличается от «разделения интересов, обязанностей, функций, классов, блоков, задач, вещей, чтобы повысить гибкость внесения изменений в программное обеспечение». Отделение базы данных от представления и представления от бизнес-логики с использованием таких методов, как инструменты и методы DI и OO, я считаю разделением MVC.

Итак, в следующий раз, когда вы объясните MVC не программисту, который, например, имеет опыт работы в сфере продаж и бухгалтерского учета, что бы вы им сказали?

Вы не объясняете MVC.

Что вы делаете, это объясняете, что это реструктуризация кодовой базы.

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

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

Другими словами - говорите с ними на их языке.

Хотя я одобряю суть ответа Одеда , что вам следует объяснять технические проекты руководителям предприятий на «их языке», я сомневаюсь в том, что «им не нужно знать технические детали, просто почему это было сделано».

Если вы участвуете в совещании по обзору проекта или инвестиционной деятельности с руководителями департаментов и заявляете, что «это то, что мы делаем», они могут спросить: «Хм… почему? Это похоже на большие затраты времени и энергии. Не могли бы вы дать нам немного больше понимания, что вы делаете и почему? " Это кажется чрезвычайно разумным вопросом. Вы не хотите, чтобы вас поймали на позиции «Ну ... это сложно». или «Нет, я не могу это объяснить». или «Не беспокойся об этом». Чем старше сотрудники, для которых вы проводите обзор проекта, тем меньше вероятность того, что они позволят «это просто вещи, которые я не могу объяснить хорошо». Лучше, если вы сможете пройти хотя бы на один уровень глубже, чтобы другие чувствовали себя комфортно, чтобы 1) вы знали, что вы '

Итак, имейте эскиз MVC в вашем набедренном кармане, готовый к работе. Что-то типа:

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

Даже если в конце они не до конца понимают MVC, и даже если вам пришлось чрезмерно упростить его, чтобы сделать его понятным («разбить несколько яиц, чтобы приготовить омлет»), держу пари, вам будет гораздо удобнее иметь готовое объяснение, чем сказать «я не могу это объяснить» или «вы не квалифицированы, чтобы понять это» старшим менеджерам.

для повышения гибкости внесения изменений в программное обеспечение

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

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

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

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

• Модель - Провода / Электричество
• Вид - Светильник
• Контроллер - выключатель света

Относительно легко выключить компоненты (светильник, выключатель света / диммер). Может быть, не так много проводки, но все же можно сделать без воздействия на другие компоненты. Каждый должен иметь возможность визуализировать это в своей голове, даже типы маркетинга / продаж. (Четкое разделение и т. Д.)

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

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

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

Лучшая рубрика: «Нам нужны модели SMART, контроллеры THIN и представления DUMB»

Как и в случае с другими шаблонами разработки программного обеспечения, MVC выражает « ядро решения » проблемы, позволяя адаптировать ее для каждой системы. Это лучше рассматривать как концепцию, а не как конкретную реализацию. Есть много реализаций концепции.

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

Для тех из вас, кто не знает, MVC был первоначально описан в виде шаблона проектирования для использования с Smalltalk Тригве Реенскаугом в 1979 году . Его статья была опубликована под названием «Программирование приложений в Smalltalk-80: как использовать Model-View-Controller» и заложила основу для большинства будущих реализаций MVC.

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

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

Помимо этого, давайте ответим на вопрос:

Я считаю полезным использовать аналогии, понятные деловым людям. Для MVC я описываю это как бизнес.

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

Преимущество объяснения этой аналогии заключается в том, что хороший менеджер увидит мудрость в разделении проблем таким образом и может решить, что они должны быть более похожими на контроллеры, а не слишком увлекаться деталями в будущем!

Это, надеюсь, ответит на вопрос «что» - «почему» также легко с этой аналогией:

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

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

** Отказ от ответственности - если ваша компания плохо организована, они могут обидеться на это. В этом случае вам понадобится другая аналогия. Вам также может понадобиться другая работа.

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

Это позволяет людям сосредоточиться на том, что они делают лучше всего.

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

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

Приведите реальные примеры архитектур MVC: сотовые телефоны, настольные телефоны, Skype и т. Д. Изменение вида (типа клавиатуры, динамиков, микрофонов) не влияет на модель (аудиосигнал), контроллер является схемой в телефон, который переводит звуковые волны в звуковые сигналы.

Я бы сказал им, что MVC разделяет мои опасения.

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

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

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

(Я не буду рассказывать им эту следующую часть) Итак, по порядку, мои объяснения были для модели, контроллера и вида.

Объяснить преимущества

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

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

Модель

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

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

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

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

Вид

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

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

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

Контроллер

Контроллер связывает модели с видом. Это держит все отдельно. Вы можете подключить в другом виде очень легко. Если вы измените код модели, представление даже не нужно знать.

Другие преимущества

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

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

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