Блог

Обзор

Я создаю простое веб-приложение, состоящее из холста и элементов на холсте.

Canvas поддерживает следующие операции: загрузка, сохранение

Элементы поддерживают следующие операции: перемещение, изменение размера

JavaScript на веб-странице отправляет сообщение серверу для каждой операции, и сервер отправляет соответствующий ответ.

Мой дизайн

Примечание: стрелка между объектами Canvas и Element должна обозначать, что объект Canvas содержит список объектов Element. У меня не было правильных символов для диаграммы.

Пример рабочего процесса

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

Вопрос

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

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

обычно у вас не будет одного контроллера, вызывающего другой в MVC. То, что вы указали в качестве контроллера элемента, на самом деле является просто частью бизнес-логики для обновления модели canvas. Если ваш вариант использования требует, чтобы вы обновляли элементы независимо от Canvas, тогда у вас будет отдельный контроллер элемента, вызывающий бизнес-логику для обновления элемента.

Приветствую, Райан

Ваша ситуация вызывает фундаментальные вопросы при попытке упорядочить проблемы в клиентском JavaScript для MVC.

Первый фундаментальный вопрос

1) Должна ли вся «страница» использовать одну монолитную Controller , где методы-члены такого Controller являются обработчиками событий / отправными точками для работы с одним Model и единственным View для всей страницы?

Говорите в регулярном выражении…

 Controller{1}

Model{1}

View{1}
  

Поскольку существует только один Controller , нет никакой двусмысленности в идее, что его методы должны служить обработчиками событий / прослушивателями для ввода в схему: Controller.moveCircle() .

Прикидываюсь дурачком на минуту, если есть только один Model , то вы можете просто перейти в одно место, чтобы создать все необходимые вам методы обработки данных / состояний. Верно? (хехехе) 😉 Model.calculatePosition() , Model.calculatePrice()

В самом базовом клиентском / веб-сценарии, если есть только один View , можно подумать, что простое размещение всей логики представления могло бы выполнить работу: View.repositionCircle(x, y) , View.repositionTriangle(x, y)

Обсуждение 1

Почему монолитная Controller , Model или View подобная схема может быть проблематичной в будущем?

Могу ли я перенести отдельные элементы экрана и их поведение на другие «страницы» без каких-либо хлопот или дополнительного багажа?

Сцепление и когезия

Подумайте о связывании. Связывает ли монолитная система цели доступа к экрану Controller свободно или плотно?

Подумайте о сплоченности. Связано ли поведение / методы монолитной Controller группы с доступом к отдельной цели сильно или слабо?

Будет ли Controller.moveCircleUp() и Controller.moveTriangleUp() иметь дело с доступом к одному целевому экрану или двум?

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

Тем не менее, если это тоже монолит, то он должен обрабатывать данные / состояние всех целевых объектов экрана. Даже при использовании нескольких свойств объекта и нескольких методов в такой модели это может привести к беспорядку.

Повторное использование и ремонтопригодность

То, о чем я здесь написал, не может быть хорошо для повторного использования кода и ремонтопригодности. Даже если вы не являетесь СОЛИДНЫМ экспертом, легко понять, почему монолиты, как правило, нарушают принцип единой ответственности. Вы не должны находиться в одном и том же месте, чтобы что-то изменить в круге, где вы также вносите изменения для треугольника.

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

If you are coupled at the hip, you might hit each other in the face or make some other error that would not have happened if each was a single floater.

In other words, it is better to operate independently and work together, than it is to be joined at the hip and try to accomplish the same things. It is not about when things go well. It is about when thing go wrongly, or when independence is preferable. For example, when one is able to grab a rope ladder dangling from a helicopter, but the other is getting gnawed on by a shark.

You want to be able to reuse application elements in different screens or applications altogether. This is why loose coupling and strong cohesion are fundamental to object-oriented programming, and programming generally.

(**Note: View does not mean HTML only, even if this is the most common end result. Other possibilities include SVG, XML, Canvas graphics, image formats … anything that fits the circumstance.)

Second Fundamental Question

2) Should each crafted, actionable object / element / target on the screen have its own Controller , Model , and View ?

Говорите в регулярном выражении…

 Controller  (one or more)

Model       (one or more)

View        (one or more)
  

Обсуждение 2

Хотите ли вы использовать экранные цели / элементы на других страницах / экранах и привносить в них их специфическое поведение?

В первом сценарии существует соотношение 1: 1: 1 между Controller , Model и View . Они монолитны. Есть один экран / веб-страница. При такой настройке вы не можете взять круг и поместить его на другую страницу / экран, не применив логику и для треугольника!

Если цель состоит в том, чтобы сделать код повторно используемым в другом контексте, то ответ заключается в том, что для каждой формы требуется автономная компоновка MVC. У каждого целевого объекта будут свои Controller , Model и View .

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

Заключительные мысли

Если принять вышесказанное как истинное, то формы, ну, в общем, живые. 🙂 Они не зависят от контекста. Манипулирование ими не должно зависеть от того, что сначала должен быть запущен какой-то всеобъемлющий оверлорд обработки событий JavaScript FrontController , только для делегирования работы отдельному методу целевого объекта Controller .

PHP MVC

Серверный PHP использует FrontController схему, прежде чем перейти к желаемому Controller подклассу, потому что, если у вас есть единственная точка входа в приложение (/index.php ), вы должны преобразовать (направить) HTTP-запрос (/contact/send) в экземпляр a Controller и вызвать нужный метод с этого контроллера: ContactController->send() .

Производительность

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

Ответ? Чем больше у вас происходит, тем больше памяти вы будете использовать. Если для каждого элемента экрана используется минимум три (3) файла Controller , Model и View , то десять элементов могут означать как минимум тридцать (файлов для загрузки).

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

Я надеюсь, что это поможет!