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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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