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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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