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()
Мне кажется, что такой подход немного неаккуратный / хакерский, но у меня нетЯ не нашел лучшего решения ...
Любой вклад / мысли с благодарностью!