微风：setDeleted的行为 [英] breeze: behavior of setDeleted

问题描述

我有一个显示实体列表的网格。

I have a grid which shows a list of entities.

每行都有一个删除按钮。

Each row has a delete button.

用户单击给定实体的删除按钮后，我想更改该行的CSS并将删除按钮替换为取消按钮。

Once the user clicked on the delete button for a given entity I want to change the css of the row and to replace the delete button with a cancel button.

所以在删除按钮事件处理程序上，我这样做：

So on the delete button event handler, I do :

myEntity.entityAspect.setDeleted();

但是，一旦我这样做，该实体就会从集合中删除，并且该行将从

But as soon as I do that, the entity is removed from the collection and the row disappear from the grid.

有没有办法防止这种情况？我只想将实体标记为已删除，并推迟任何更改，直到用户单击保存按钮。

Is there a way to prevent that ? I just want to mark the entity as 'deleted', and postpone any change until user clicks on save button.

我唯一看到的选择是添加一个属性isDeleted我的客户端模型，并以此为基础。但这意味着我必须自己处理更改跟踪，并在保存时遍历实体，以为isDeleted属性为true的实体调用setDeleted。我不喜欢这种解决方案。微风让我更想念什么吗？

The only alternative I see, is to add a property isDeleted to my client-side model and to base my logic on that. But it means I have to handle change tracking myself and loop through the entities on save to call setDeleted for entities which isDeleted property is true. I'm not fond of this solution. Is there something better I'm missing with breeze ?

推荐答案

1）的问题是，当删除一个实体时，我们需要切断其与任何其他实体的关系。这确实是删除的本质，我们希望环境在提交删除后看起来像它一样（通过EntityManager.saveChanges（））

The problem with 1) is that when you delete an entity we need to sever its relationships with any other entities. This really is the essence of deleting, we want the environment to look like it will after the delete is committed ( via EntityManager.saveChanges())

当您说自己我不希望删除后将导航属性设置为null我假设您正在谈论的是标量（1-> 1）或（n-> 1）导航。 （非标量导航只是从集合中删除实体）。第一个问题是您要谈论的是到已删除的实体还是从已删除的实体。在不删除导航到已删除实体的情况下，我们将导致许多（如果不是大多数）现有的微风应用程序失败。大多数应用程序希望看到实体在删除时消失。

When you say that you do not want the navigation properties to be set to null after a delete I am assuming that you are talking about a scalar (1->1) or (n->1) navigation. (nonscalar navigations simply remove the entity from the collection) The first issue is whether you are talking about navigations 'To' the deleted entity or 'From' the deleted entity. In the case of 'NOT" removing the navigation 'to' a deleted entity we would be causing many if not most existing breeze apps to fail. Most apps expect to see entities disappear when you delete them.

在不从删除的实体中删除导航的情况下，该概念更有意义，除了会引起另外两个问题外，第一个是这会破坏任何双向导航，即您将无法再在从和到导航之间往返，但更重要的是，我们将删除视为最终分离操作（在成功保存后会发生）的先决条件。 分离是指它恢复了内存，因为我们已经有效地删除了对已删除对象的所有引用，这意味着可以对其进行垃圾回收。如果我们保留任何导航属性，那么该垃圾回收将永远不会发生，最终

In the case of 'NOT' removing the navigation 'from' a deleted entity, the concept make more sense except that you cause two more issues. The first is that this breaks any 'bidirectional' navigations, i.e. you can no longer roundtrip between the 'from' and 'to' navigations. But more importantly, we view a 'delete' as a precursor to an eventual 'detach' operation ( which will occur after a successful save). The primary value of the 'detach' is that it recovers memory because we have effectively removed any references to the 'deleted' object, which means that it can be garbage collected. If we leave any navigation properties intact this garbage collection will never occur, and we end up with a memory leak.

我们可以通过分离来解决此问题该操作还删除了导航属性，但规则开始变得难以解释。

We could get around this by having the 'detach' operation also remove navigation properties but the rules begin to get harder to explain.

如果您仍然对此有强烈的感觉，请将您的建议发布到Breeze用户之声。如果我们对此有一定的兴趣，我们将尝试提出一种解决方案，但目前我们对此还没有一个很好的答案，而这并没有增加真正的概念复杂性。 （我们确实尝试避免的事情）。

If you still feel strongly about this, please post your suggestion to the Breeze User Voice. If we see some substantial interest in this, we will try to come up with a solution, but right now we don't have a good answer to this that doesn't add real conceptual complexity. (Something we really try to avoid).

能否提供有关您看到的验证的更多信息？这些验证是在已删除实体还是指向已删除实体的仍然有效的实体上进行的？没有第一次发生很有意义（如果是这种情况，我们应该纠正它），没有第二次发生没有意义，因为您确实造成了真正的验证失败。

Can you give more detail about the 'validations' that you are seeing? Are these validations on the 'deleted' entity or on the still alive entities that were pointing to the deleted entity? Not having the first occur makes a lot of sense (and we should fix it if this is the case), not having the second occur does not make sense because you really are causing a real validation failure.

这篇关于微风：setDeleted的行为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！