Нужны некоторые пояснения на стороне модели MVC

Question

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

1. В целом же модель, как описано в рамках как Robotlegs играют роль держателя государственной заявки, или владелец государственного домена? Первоначально я думал, что модели полностью основаны на доменах, то есть UserModel, LocationModel, которые играют ту же роль, что и классы DAO на сервере. Чем больше исходный код, на который я смотрю, тем больше я вижу такие вещи, как UserAccountModel, ShoppingCartModel и т. Д., Полные свойств и методов, связанных с состоянием клиентского приложения, а не состояния домена.

2. Я вижу, что люди не утруждают себя сложными отношениями к классам VO, то есть, если у Пользователя много фотографий, коллекция фотографий, очевидно, не указана в классе UserVO. Вместо этого при необходимости загружается множество объектов PhotoVO с сервера на основе вызова службы с идентификатором пользователя. Это что-то вроде эмпирического правила - вообще говоря, VO «как можно»? Разве это не увеличивает возможное количество вызовов, которые должны быть сделаны сервером для извлечения всех данных? Более того, разве это не фрагмент общей модели домена? (объект Пользовательский класс на сервере всегда будет иметь свойство фотографий)

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

Answer 1

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

Я действительно не понимаю ваше различие между «Доменным государством» и «Состояние приложения». Тем не менее, я считаю, что любые классы стиля «Value Object», реализованные в пользовательском интерфейсе, должны быть сосредоточены на сохранении состояния определенных представлений. Чрезвычайно редко, что одно представление является отношением «один к одному» к таблицам базы данных. Таким образом, мои объекты данных пользовательского интерфейса могут быть не идентичны объектам данных на стороне сервера. Хотя, очень распространено, что я буду отображать объекты пользовательского интерфейса на серверные объекты с использованием AMF. Но это не означает, что каждый объект в пользовательском интерфейсе реализован на стороне сервера, и каждый объект сервера реализован в пользовательском интерфейсе.

Я вижу, что люди не удосужились добавить сложные отношения к классов VO,

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

С таким количеством вызовов на сервер, как правило, требуется получить некоторые объекты , которые могут быть уже на клиентском хранилище.

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

Повторюсь, моя первоначальная оценка: Я думаю, что ответы на большинство ваших вопросов зависят от ситуации и зависят от приложения. Кажется, вы начинаете с чрезвычайно широких обобщений о том, как дела обстоят. Однако я не верю, что они универсальные истины. Борьба разработчиков с архитектурой приложений все время.