Блог

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

Поскольку приложение основано на интенсивном взаимодействии с графическим интерфейсом, я думал об использовании шаблона проектирования MVC, дело в том, что у меня возникли проблемы с определением, какая часть должна существовать на сервере, а какая на стороне клиента. Другими словами, нормально ли иметь Представление (т.Е. Граничные классы и объекты GUI) и контроллер на стороне клиента, оставляя модель (т. Е. Объекты Entity) на стороне сервера; является ли это жизнеспособным или допустимым способом применения шаблона MVC? Я иду в правильном направлении здесь? Возможно ли это вообще? Я имею в виду, могут ли эти граничные и управляющие классы работать и выполняться без наличия или доступа к классам моделей на одном компьютере или процессе?

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

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

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

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

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

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

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

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

Есть еще много причин, но я думаю, что приведенное выше демонстрирует суть.

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

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

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

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

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

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

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