BreezeJS - Цепочка запросов

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

Я просто сосредоточусь на «цепочке» и предполагаю, что вы хотите, чтобы вызывающий абонент завладел выбранным клиентом, когда вы закончите.

Последовательная цепочка

В этом примере мы ждем клиента перед тем, как получить Foos

function getCustomer(custId) {

    var cust;
    var em = this.em;
    var query = breeze.EntityQuery().from("Customers")
                .where("CustomerId", "==", custId);

    // On success calls `gotCustomer` which itself returns a promise
    return em.executeQuery(query)
        .then(gotCustomer)
        .fail(handleFail); // you should handleFail 

    // Called after retrieving the customer.
    // returns a new promise that the original caller will wait for.
    // Defined as a nested success function 
    // so it can have access to the captured `cust` variable 
    function gotCustomer(data) {
       cust = data.results[0];

       if (!cust) {
          return null; // no customer with that id; bail out now
       }
       // got a customer so look for non-customer foos
       // returning another promise so caller will wait
       return breeze.EntityQuery().from("Foos")
              .where("CustomerId", "!=", custId)
              .using(em).execute()
              .then(gotFoos);
    }

    // Now you have both the customer and the other Foos;
    // bring them together and return the customer.
    function gotFoos(data) {
        var foos = data.results;
        // assume `notMyFoos` is an unmapped property that 
        // should hold every Foo that doesn't belong to this Customer
        foos.forEach(function(f) { cust.notMyFoos.push(f); }
        return cust; // return the customer to the caller after Foos arrive.
    }
}

Параллельные асинхронные запросы

В вашем сценарии вам действительно не нужно ждать запроса клиента, прежде чем получить foos. Вы с самого начала знаете критерий выбора как для покупателя, так и для любителя. Предполагая, что существует высокая вероятность того, что запрос клиента вернет клиента, вы можете запустить оба запроса параллельно, а затем объединить данные, когда оба запроса будут завершены. Рассмотрим для этого Q.all.

function getCustomer(custId) {
    var em = this.em;

    var custPromise = breeze.EntityQuery().from("Customers")
                      .where("CustomerId", "==", custId)
                      .using(em).execute();

    var fooPromise = breeze.EntityQuery().from("Foos")
                      .where("CustomerId", "!=", custId)
                      .using(em).execute();

    Q.all([custPromise, fooPromise])
      .then(success)
      .fail(handleFail); // you should handleFail

    // Now you have both the customer and the "other" Foos;
    // bring them together and return the customer.
    // `data` is an array of the results from each promise in the order requested.
    function success(data) {
        var cust = data[0].results[0];
        if (!cust) return null;

        var foos = data[1].results;

        // assume `notMyFoos` is an unmapped property that 
        // should hold every Foo that doesn't belong to this Customer
        foos.forEach(function(f) { cust.notMyFoos.push(f); }
        return cust; // return the customer to the caller after Foos arrive.
    }
}

Обратите внимание, что мне не нужно делать так много проверки на null в путях успеха. У меня гарантированно будет data.results при вызове успешного обратного вызова. Я действительно должен учитывать возможность того, что Customer не совпадает с custId.