排序微风导航属性 [英] Sorting Breeze navigation properties

问题描述

如何对微风实体中的一组实体进行排序?例如，如果我的订单中有很多商品，如何按orderDate对商品进行排序?

How do I go about sorting a set of entities in a breeze entity? For example if I have an order with many items, how do I sort the items by orderDate?

    <div databind="ko with: order">
           <ol databind="foreach: items">
              <li/>
           </ol>
    </div>

此外，我不能在数据绑定中使用items.sort()，因为我正在使列表项可排序. HTTPS://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CDYQFjAA&url=https%3A%2F%2Fgithub .com％2Frniemeyer％2Fknockout-sortable& ei = 8BJ3UaXZMMGG2wW5yoGQCw& usg = AFQjCNFnjZ_6ths9dl_UW9BpJkFO3Yi6kA& sig2 = swWZW7Rq6Ib

Also, I can't use items.sort() in the data-bind, because I am making the list items sortable. https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CDYQFjAA&url=https%3A%2F%2Fgithub.com%2Frniemeyer%2Fknockout-sortable&ei=8BJ3UaXZMMGG2wW5yoGQCw&usg=AFQjCNFnjZ_6ths9dl_UW9BpJkFO3Yi6kA&sig2=swWZW7Rq6IqAcIX2-2Cl6w&bvm=bv.45580626,d.b2Istrong text

推荐答案

我认为简短的答案是你不能". Breeze实体属性是简单，无序的ObservableArray，因为它们是模型的一部分.

I think the short answer is "you can't". The Breeze entity properties are simple, unordered ObservableArrays because they are part of the model.

您要实现的是UI效果...，严格来说，它不属于模型.该模型应该独立于UI.如果订单数据存储在SQL数据库中，则该订单项的顺序在此严格未定义.

What you want to achieve is a UI effect ... which, strictly speaking, does not belong in the model. The model is supposed to be UI independent. If the Order data are stored in a SQL database, the sequence of the Order's items is strictly undefined there.

足够的理论.你有工作要做.我该怎么办?两件事之一

Enough theory. You have work to do. What might I do? One of two things

"OrderViewModel"是"ItemViewModel"，它是具有特殊能力"支持视图的模型对象的包装. OrderViewModel可以公开其包装的Order对象以绑定其大多数属性.但是，当您需要特殊的东西(例如排序的物品")时，您可以在OrderViewModel上创建 KO属性以用于显示……将其命名为"sortableItems"并绑定到您的看法.

"OrderViewModel" is an "ItemViewModel" which is a wrapper around a model object that has "special powers" in support of a view. The OrderViewModel can expose its wrapped Order object for binding most of its properties. But when you need something special ... such as your sorted "items" ... you create a KO property on the OrderViewModel for display purposes ... call it "sortableItems" and bind to THAT in your view.

这是一个简单的伪代码实现:

Here's a simplistic, pseudo-code implementation:

app.OrderViewModel = function(order) {
   this.order = order;
   this.sortableItems = ko.observableArray();

   this.resetSortableItems();
}

app.OrderViewModel.prototype.resetSortableItems() {
    // (re)initialize with copy of the items
    this.sortableItems(this.order.items().slice(0));
    // maybe some ordering logic here?
}

您的"sortableItems"将按照您希望的方式覆盖内部Order.items；也许可以通过您引用的KO-Sortable功能对其进行排序.

Your "sortableItems" covers the inner Order.items in the manner that you intended; it would be sortable, perhaps by means of the KO-Sortable feature to which you referred.

最困难的部分(未显示)使它与内部Order.items属性在添加或删除项目时保持同步.请记住，内部的Order.items属性是真实的真实来源.也许您很幸运，可以完全控制可以添加/删除项目的任何内容；那么您可以仅在发生这些更改时调用resetSortableItems方法.

The hard part (not shown) is keeping it in sync with the inner Order.items property when items are added or removed. Remember the inner Order.items property is the real source of truth. Maybe you're luck and in complete command of whatever can add/remove items; then you can just call the resetSortableItems method when those changes occur.

这是我能带你去的地方.

This is as far as I can take you.

也许您已经决定不成为一个纯粹主义者.您愿意修改模型实体以使其与您的UI良好配合.因此，您添加了我刚刚描述的KO-Sortable属性...但将其添加到Order实体在自定义初始化程序中，而不是在OrderViewModel中.

Maybe you've decided not to be such a purist. You're willing to modify the model entity to make it play well with your UI. So you add that KO-Sortable property that I just described ... but add it to the Order entity in a Custom Initializer rather than to an OrderViewModel.

这可以为您简化事情.另一方面，您(a)担心UI污染了Order实体，并且(b)将自己限制为一种项目，该项目将适用于引用给定Order的所有视图.要(a)您可以说"谁在乎?"(我一直都这样做).但是(b)可能是个问题...在这种情况下，您可以返回OrderViewModel以获取最大的灵活性.

This may simplify things for you. On the other hand, you've (a) polluted the Order entity with UI concerns and (b) limited yourself to a single sort of the items which would apply to all views that reference a given Order. To (a) you may say "who cares?" (I do it all the time). But (b) may be a problem ... in which case you go back to the OrderViewModel for maximum flexibility.

这篇关于排序微风导航属性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！