Использование MVC (Model View Controller) в архитектуре клиент-сервер

Question

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

Сприложение основано на интенсивном взаимодействии с графическим интерфейсом, я думал об использовании шаблона проектирования MVC, дело в том, что у меня возникают проблемы с выбором, какая часть должна существовать на сервере, а какая на стороне клиента.Другими словами, можно ли иметь View (то есть классы и объекты GUI Boundary) и контроллер на стороне клиента, оставляя при этом Model (т.е. объекты Entity) на стороне Сервера;Это жизнеспособный или действительный способ применения шаблона MVC?Я иду в правильном направлении здесь?Это вообще возможно?Я имею в виду, могут ли эти классы Boundary и Control работать и выполняться без наличия или доступа к классам Model на одной машине или в процессе?

Должен ли я иметь все это (классы Model, View и Controller) на стороне клиентаа затем просто связаться с базой данных сервера по протоколу?

Любые предложения или комментарии будут приветствоваться.

Answer 1

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

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

Некоторые вещи, на которые я бы посмотрел:

• сеть: сколько данных необходимо перенести между клиентом и сервером?Сколько запросов обычно отправляет приложение?(слишком много может насытить сеть или вызвать другие проблемы)

• отзывчивость: более высокая скорость отклика может потребовать от вас большего в клиенте

• безопасность: все, что идет по проводам, может быть менее защищено

• производительность: если вам нужна высокая производительность, вам могут понадобиться компоненты на сервере

• ожидаемые нагрузки: вы можете решить разместить больше компонентов на стороне клиента для разгрузки сервера, а не кластеризовать свой бэкэнд, например

• и т. д.

Answer 2

Ваши мысли об использовании MVC совершенно правильны. Это поможет вам избавиться от проблем и даст вам больше контроля над занятиями.

Я бы предложил сохранить вид на стороне клиента. Я хотел бы сохранить класс контроллера и модели на сервере. Контроллер - это сложный компонент. Можно легко поддаться искушению сохранить его на клиенте, причины его размещения на сервере: взаимодействие с DAO, взаимодействие с классами модели, обработка ошибок и поток управления (экранов / действий).

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

Answer 3

Вы не можете применить традиционный MVC к архитектуре сервер-клиент.Причины включают в себя:

• Сервер и клиент имеют различные среды выполнения и API.
• У вас должна быть некоторая бизнес-логика на сервере дляиз соображений безопасности, но если каждое пользовательское действие не совершит обратного обращения к серверу и обратно, у вас также должна быть некоторая бизнес-логика на стороне клиента (подумайте о проверке формы).Фактически это означает, что у вас есть модель на обоих .
• . В традиционных MVC контроллеры поддерживают ссылку на модель.Контроллер на стороне клиента не может на самом деле хранить ссылку на модель на сервере, потому что фасад сети.
• Более того, в традиционном MVC слой модели имеет все записи модели,Во многих веб-приложениях клиент получает только частичную модель (представьте себе страницу 1 из 3).
• Два последних пункта также означают, что (частичная) модель вашего клиента на самом деле не вашамодель - если для одной модели есть два представления (например, список клиентов с разбивкой по страницам и раскрывающийся список с удаленным поиском в другом представлении), то также есть два контроллера - каждый со своей моделью.Таким образом, модель в действительности представляет собой модель фантомного вида , а не реальную модель.

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

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

Answer 4

После долгих исследований и разработок я обнаружил наилучшую производительность с большинством контроллеров и видом на клиент, а также с небольшой частью контроллера и модели на сервере.Затем можно было бы сказать, что контроллер был распределен по клиенту и серверу - преимущество в том, что если контроллеру нужны ресурсы, которые уже кэшированы в клиенте, он фактически избегает сетевого трафика, что важно для обеспечения быстрой работы.Вот пример: http://www.youtube.com/watch?v=g73GcQqrDeA

В основном я обнаружил, что производительность была плохой, если использовать такие вещи, как серверные движки шаблонов или что-то, что может пропустить кеш из браузера, поэтому все html должны быть на 100%статичный.Используя только jQuery, он предоставляет действительно полезные средства привязки событий, которые вы можете делегировать классу контроллера, который также можно кэшировать в браузере.В конце концов, единственными данными, возвращающимися назад и вперед, являются JSON - просто позаботьтесь о том, чтобы сделать ваш сервер безопасным, закодируйте / зашифруйте все важные идентификаторы, убедитесь, что они не совпадают даже для одного и того же пользователя между сеансами и т. Д.1004 *