Несколько RemoteObjects - лучшие практики

Question

У меня есть приложение с около 20 моделями и контроллерами, и я не использую какую-либо конкретную платформу. Каков наилучший способ использования нескольких удаленных объектов в Flex с точки зрения производительности?

1) Метод 1 - Один на компонент - Каждый компонент создает для себя RemoteObject

2) Метод 2 - множественный в корне приложения - Каждый контроллер обрабатывается объектом RemoteObject в корне

3) Метод 3 - Один в корне приложения - Объедините все контроллеры в один класс и обработайте их одним RemoteObject

Я предполагаю, что 3 будет иметь лучшую производительность, но будет слишком грязной, чтобы поддерживать, и 1 будет самым чистым, но нанесет удар по производительности. Что ты думаешь?

Answer 1

Лучшей практикой будет «ничего из вышеперечисленного». Ваши представления должны отправлять события, которые контроллер или компонент Command будут использовать для вызова ваших служб, а затем обновлять вашу модель при возврате данных. Ваши представления будут привязаны к данным, и затем представления будут автоматически обновляться новыми данными.

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

Итак, где живут ваши службы, чтобы контроллер или команда могли получить к ним доступ? Если вы используете платформу Dependency Injection, такую ​​как Robotlegs или Swiz, у нее будет отдельный объект, который обрабатывает экземпляры, хранит и возвращает экземпляры объектов модели и сервисных объектов (в случае Robotlegs он также создаст ваши объекты Command для вас). и может создавать объекты управления видом, называемые посредниками). Если вы не используете ни одну из этих платформ, вам нужно «свернуть свою собственную», что может быть немного сложно, если вы не архитектурно настроены.

Одна вещь, к которой склонны прибегать люди, которые не знают, как кататься самостоятельно (например, люди, которые написали более старые версии Cairngorm), - это Singletons. Это не считается хорошей практикой в ​​наше время, особенно если вы вообще заинтересованы в модульном тестировании своей работы. http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singletons/

Answer 2

С точки зрения чистой производительности, все три из них должны работать примерно одинаково. Конечно, вы будете использовать немного больше памяти, имея больше экземпляров RemoteObject, и есть пара дополнительных байтов, которые отправляются вместе с первым запросом, который вы сделали с данным экземпляром RemoteObject на ваш сервер (часть протокола AMF). ). Тем не менее, влияние этих вещей незначительно. Таким образом, Эми права, что вы должны сделать выбор, основываясь на простоте обслуживания, а не на производительности.

Answer 3

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

Номер 3 (и 2) в основном синглтоны, которые лучше всего работают для больших приложений и больших наборов данных. Да, было бы сложно поддерживать себя, но именно поэтому люди склонны использовать фреймворки (puremvc, cairgorm и т. Д.). большая часть сложности обрабатывается для вас. Кэширование данных в рамках также повышает производительность и время отклика.

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

edit: я использую cairgorm - имею ~ 30 моделей доменов (около 200 удаленных вызовов), а также использую модели представлений. некоторые из моих моделей (удаленный объект) имеют 10 тысяч экземпляров объекта (записей), я сохраняю кеш с обратной записью. Вся сложность заключена в контроллере / командах. Производительность приемлема.