breeze.js и независимые транзакции

Question

Мне нужно делать меньшие SaveChanges за пределами области с расширенными возможностями SaveChanges, и я хочу иметь возможность сохранять меньшие транзакции независимо от более крупного. Пример: пользователь создает заказ с позициями. Типичная корзина для родителей и детей. Все объекты «order» создаются/сохраняются как 1 транзакция SaveChange. Пока пользователь находится на сайте, он может выбрать продукт и обозначить его как «любимый». В то время я хотел бы сохранить эту транзакцию в БД, полностью независимую от заказа (который может быть или не быть сохранен). Это будет случай для архитектуры mutli-manager? Или многофакторные тексты? Я не совсем уверен, какие различия между ними. Существует ли наилучшая практика для такого рода рабочих потоков? Если это имеет значение, я использую Durandal 2.0, и я следую шаблону проектирования singleton для моего объекта datacontext.

Answer 1

Аргумент может быть ... возможно следует ... что ваш рабочий процесс не должен позволять пользователю одновременно любимый Product и построить новый Order и имеет оба изменения будут несохраненными и обменом те же EntityManager. Это кажется мне неразумным.

Но Breeze поддерживает частичные сбережения («спасение вишни»), и вы можете воспользоваться этой функцией, если/когда у вас есть все основания для этого.

Первый параметр метода EntityManager.saveChanges - это необязательный массив сущностей для сохранения, чтобы вы могли выбирать, какие объекты сохранять в транзакции.

Много способов построить этот набор. Нечто подобное для приложения KO может работать (осторожно: непроверенный)

function saveOrderById(order){ 
    // get the order's items with pending changes 
    var itemsWithChanges = order.orderItems().filter(
     function(item) { return item.entityAspect.isAddedModifiedOrDeleted()}); 
    // concatenate with the order itself (you may have a concurrency property to set, btw) 
    var savables = itemsWithChanges.concat(order) 
    return order.entityAspect.entityManager.saveChanges(savables); // returns the promise 
} 

заносить в избранное в Product не будет частью этой сделки и будет оставаться в ожидании изменения в кэше.

БУДЬТЕ ОСТОРОЖНЫ

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

Например, пример (возможно, плохой пример), один из новых элементов заказа может ссылаться на новый Product, который вы еще не сохранили.

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

Но вы видите мою мысль, не так ли? Вы должны быть уверены, что в вашем сохранении есть все необходимое.