Когда и сколько данных загружать в модельные объекты?

Question

Я пришел к программированию iPhone из парадигмы веб-разработки, и у меня возникла небольшая проблема с пониманием того, как спроектировать приложение для iPhone.

Суть моего вопроса в следующем: сколько данных вы загружаете в своймодель и когда вы загружаете ее данными из базы данных?

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

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

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

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

Answer 1

• Для статических данных, которые не слишком велики, загрузка их при запуске работает.
• В одном из наших продуктов мы делаем это для простоты одной из таблиц (мы не ожидаем более нескольких тысяч строк) и загружаем другую таблицу лениво (изображения с высоким разрешением). Это разумный вариант, если у вас нет фоновых потоков, также обращающихся к базе данных.
• Базовые данные выполняют пакетную отложенную загрузку (т. Е. Одновременно загружает пакет строк результатов).

Sidenote: Запись с использованием Core Data и хранилища SQLite кажется исключительно медленной, поскольку мы переместили обработку в фоновый поток, чтобы избежать блокировки пользовательского интерфейса (и это совсем немного для данных ) и получил некоторые раздражающие проблемы параллелизма в результате. Вздох.