ExtJS и сложные операции сохранения

ExtJS 4.1.0

Обновление 6/6/13:

Я разместил этот же вопрос на форумах Сенчи, где нетбыло много действий. Пост более или менее такой же, но я решил добавить сюда только для справки. Я все еще хочу услышать других членов сообщества вклад в то, что должно быть очень распространенным сценарием в приложении ExtJS!http://www.sencha.com/forum/showthread.php?265358-Complex-Model-Save-Decoupling-Data-and-Updating-Related-Stores

Обновление 16.07.13 (Заключение?)

Сообщение Сенчи вызвало очень мало дискуссий. Я решил перекладывать большую часть сложных операций сохранения на сервер приложений и лениво обновлять клиентские хранилища там, где это необходимо. Таким образом, я могу использовать свою собственную обертку базы данных, чтобы охватить все транзакции, связанные с одним сложным сохранением объекта домена, чтобы гарантировать атомарность. Если сохранить новыйOrder состоит из сохранения метаданных заказа, десяти новых экземпляровOrderContents и потенциально другую информацию (адреса, находящиеся в других таблицах, новый клиент, определенный во время создания заказа и т. д.), я бы скорее отправил полезную нагрузку на сервер приложений, чем создавал бы вульгарную сеть обратных вызовов в клиентском приложении. код. Данные, которые связаны один на один (например,Order hasOneAddress) обновляется вsuccess обратный вызовOrder.save() операция. Более сложные данные, такие какOrderс содержимым, лениво обрабатывается простым вызовом.contentStore.sync()Я чувствую, что это средство гарантировать атомарность без подавляющего числа обратных вызовов

Оригинальный контент

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

Возьмите, к примеру, сохранениеOrder объект, который состоит из метаданных, а такжеOrderContents части на заказ. Метаданные заканчиваются вOrder_Data таблица в базе данных, в то время как все содержимое в конечном итогеOrder_Contents таблица, где каждая строка связана с родительским заказом черезorder_id колонка.

На клиенте получение содержимого заказа довольно просто, без каких-либо ассоциаций:var contents = this.getContentsStore().query('order_id', 10).getRange(), Тем не менее, основным недостатком является то, чтоэто зависит от содержания записей, доступных вOrderContents Магазин ExtJS, что применимо, если бы я использовал ассоциации, НЕ возвращаемые сервером данных с "главный" объект.

Сохраняя заказ, я отправляю один запрос, который содержит заказ.s метаданные (например, дата, номер заказа, информация о поставщике и т. д.), а также массив содержимого. Эти фрагменты данных отбираются и сохраняются в соответствующих таблицах. Это имеет достаточно смысла для меня и работает хорошо.

Все хорошо, пока не вернется сохранение / обновление записей с сервера приложений. Так как запрос выполняется с помощью вызоваOrderObject.save()Нечего рассказыватьOrderContents хранить, что новые записи доступны. Это было бы обработано автоматически, если бы я вместо этого добавил записи в хранилище и позвонил.sync(), но я чувствую, что это усложняет процесс сохранения, и я бы просто предпочел справиться с этой развязкой на сервере приложений, не говоря уже о сохранении всего запроса.

Есть ли лучший способ решить эту проблему? Мое текущее решение заключается в следующем ...

var orderContentsStore = this.getOrderContentsStore();
MyOrderObject.save({
    success: function(rec, op){
        // New Content Records need to be added to the contents store!
        orderContentsStore.add(rec.get('contents')); // Array of OrderContent Records
        orderContentsStore.commitChanges(); // This is very important
    }
});

По телефонуcommitChanges() записи, добавленные в хранилище, считаются чистыми (не фантомными, не грязными) и, следовательно, больше не возвращаются хранилищемgetModifiedRecords() Способ; правильно, поскольку записи не должны передаваться на сервер приложений в случаеstore.sync()

Мне кажется, что такой подход немного неаккуратный / хакерский, но у меня нетЯ не нашел лучшего решения ...

Любой вклад / мысли с благодарностью!

Ответы на вопрос(1)

Ваш ответ на вопрос