breeze - 来自已加载实体的 Breeze 投影查询

Question

如果我使用微风加载部分实体:

    var query = EntityQuery.from('material')
        .select('Id, MaterialName, MaterialType, MaterialSubType')
        .orderBy(orderBy.material);

        return manager.executeQuery(query)
            .then(querySucceeded)
            .fail(queryFailed);

        function querySucceeded(data) {
            var list = partialMapper.mapDtosToEntities(
                manager, data.results, entityNames.material, 'id');
            if (materialsObservable) {
                materialsObservable(list);
            }
            log('Retrieved Materials from remote data source',
                data, true);
        }

...而且我还想从同一个实体中进行另一个稍有不同的部分查询(例如，可能还有其他几个字段)，那么我假设我需要执行另一个单独的查询，因为在第一个字段中未检索到这些字段查询？

好的，如果我要使用在第一个查询中检索到的相同字段(Id，Materialname，MaterialType，MaterialSubType)，但又想在第二个查询中将这些字段称为不同的名称(Materialname变成“name”，MaterialType变成“masterType”等)，然后可以克隆我已经在内存中的部分实体(假设它在内存中吗？)并重命名字段，还是我仍然需要做一个完全独立的查询？

Answer 1

如果可以的话，我想我会将这两种情况“结合”在一起。那将大大简化事情。但是了解以下几点确实很重要:

您无需将查询投影结果转换为实体!

Backgound:CCJS示例

您可能已经从John Papa精湛的PluralSight class “Single Page Apps JumpStart”中的CCJS示例中学到了投影到实体的技术。 CCJS出于某种特定原因使用此技术:简化列表更新，而无需访问服务器。

考虑由投影查询填充的CCJS“ session 列表”。 John不必将查询结果转换为实体。他本可以直接约束预期的结果。请记住，淘汰赛可以愉快地绑定(bind)到原始数​​据值。用户从不直接编辑该列表上的 session 。如果显示的 session 值无法更改，则将它们转换为可观察的属性会浪费CPU。

当您点击一个 session 时，您将进入一个 session View /编辑屏幕，可以访问整个 session 实体的几乎每个属性。 CCJS需要那里的完整实体，因此它将在缓存中查找完整(而非部分) session ，如果找不到，则从服务器加载该实体。即使到这一点，事先将原始投影结果转换为(部分) session 实体也没有特殊价值。

现在编辑 session -更改标题-并保存它。返回“ session 列表”

题

您如何确保更新的标题出现在“ session 列表”中？

如果我们将“ session 列表” HTML绑定(bind)到投影数据对象，则这些对象不是实体。它们只是对象。您在 session View 中编辑的实体不是“ session 列表”中显示的集合中的对象。是的，列表中有一个对应的对象-一个具有相同 session id的对象。但这不是同一对象。

选择项

＃1 :通过重新发布投影查询从服务器刷新列表。直接绑定(bind)到投影数据。请注意，数据由原始JavaScript对象组成，而不是实体。它们不在微风缓存中。

＃2 :保存真实 session 实体后发布事件；订阅“ session 列表”的ViewModel会听到事件，提取更改，并在列表中更新其 session 副本。

＃3 :使用投影到实体技术，以便可以在任何地方使用 session 实体。

利弊

＃1 很容易实现。但是，每次您进入“ session 列表” View 时，都需要服务器跳闸。

CCJS的设计目标之一是，一旦加载，它就应该能够完全脱机运行，并且对服务器的访问权限为零。当连接断断续续且较差时，它应该可以清晰地工作。

CCJS是您随时准备参加 session 的指南。它会立即告诉您哪些 session 可用，何时何地可用，这样您就可以在走过大厅到达那里时找到所需的 session 。如果您去过一次技术 session 或酒店，您就会知道wifi通常很糟糕，并且仅当它可以直接访问服务器时，该应用程序才能工作，该应用程序几乎毫无用处。

＃1不太适合CCJS的预期操作环境。

CCJS Jumpstart沿着“独立于服务器”的道路走了一段路。您很快就会看到更接近于完全脱机实施的东西。

您还将失去导航到相关实体的能力。 session 列表显示每个 session 的轨道，时隙和房间。这是在“查找”参考实体中找到的重复信息。您将不得不扩大投影范围，以将该信息包括在 session 的“展平” View 中(分散的有效负载)，或者在客户端变得机灵并手动修补轨道，时隙和房间数据(复杂性)。

＃2 帮助进行脱机/间歇性连接方案。当然，您将必须设置消息传递系统，建立有关已保存实体的协议(protocol)，并教 session 列表查找和更新受影响的 session 投影对象。这并不是 super 困难-Breeze EntityManager发布了一个可能足够的事件-但它将花费更多的代码。

＃3 有益于“服务器独立性”，投影有效载荷小， super 易用，并且是微风的炫酷展示。您必须管理isPartial标志，以便始终知道高速缓存中的 session 是否完成。那不难。

如果您需要多种“部分实体”样式，可能会变得更加复杂...这似乎就是您要去的地方。在CCJS中，这不是问题。

John为CCJS选择了＃3，因为它符合应用程序的目标。

这并不是每个应用程序的正确选择。这可能不是您的正确选择。

例如，如果您始终具有快速，低延迟的连接，那么＃1可能是您的最佳选择。我真的不知道

我自己喜欢强制转换到实体的方法，因为它很容易并且在大多数情况下效果很好。在做出选择之前，我确实会仔细考虑一下。

概要

您要做而不是，而不必将投影查询结果转换为实体

如果它们是只读

，则可以直接绑定(bind)到投影数据，而无需Knockout可观察的属性

确保您有充分的理由将投影数据转换为(部分)实体。

CCJS有一个 充分理由可以将投影的查询数据转换为实体。你做？