asp.net mvc;一次仅适用于一个用户的编辑选项 [英] asp.net mvc; edit option only for one user at a time

问题描述

我有一个表，该表包含三个带有一些记录的字段.如果用户要编辑表中的记录，则不允许其他用户同时编辑该记录.我可以采取哪些步骤来实现这一目标?

I have a table which has three fields with a few records. If an user is going to edit a record from the table, other users won't be allowed to edit that record the same time. What kind of steps i can take to make this happen?

推荐答案

来自桌面应用程序背景的许多人都会想知道如何在Web应用程序中完成此操作.

Alot of people from a desktop application background will wonder how this is done in a web application.

在桌面世界中，一种方法是在该行上包含一个布尔列，以指示该列及其正在由谁编辑.您当然可以使用Web应用程序执行此操作，但这是一种非常糟糕的方法，因为如果用户访问编辑"页面，将记录置于锁定状态，然后离开该页面，它将永远处于锁定状态.您没有确定的方式来告诉用户仍未打开编辑页面.

One approach in the desktop world is to have a Boolean column on the row that indicates that it is being edited, and by whom. You could certainly do this with a web app, but it is a very bad approach because if a user visits the Edit page, placing the record into a locked state, then leaves the page, it will forever be in a locked state. You have no definitive way to tell that the user doesn't still have the edit page open.

航空公司预订方法是上述方法的一种变体，但是您还将拥有一个LockedUntilUtc，它是一个日期时间，指示记录被锁定的时间.假设Bob访问了一个页面进行记录，当您从GET操作提供服务时，您还设置了lock标志，并将LockedUntilUtc设置为以后的10分钟. 5分钟后，莎拉(Sarah)访问该页面，但由于您选中了LockedUntilUtc而收到了当前锁定"错误，并且该错误在将来出现.又过了6分钟(自锁定以来，总共经过11分钟)，并且有人访问了该页面，现在LockedUntil已经过去了，因此您将锁定授予新用户.

The airline reservation approach is a variation on the above, but you would also have a LockedUntilUtc which is a datetime indicating how long the record is locked for. Let's say Bob visits a page for a record, when serving the apge from the GET action you also set the locked flag, and set LockedUntilUtc to 10 minutes in the future. 5 minutes later Sarah visits the page but gets a "currently locked" error because you checked the LockedUntilUtc and it is currently in the future. Another 6 minutes elapses(total of 11 minutes since locked) and someone visits the page and the LockedUntil is now in the past, so you give the lock to the new user.

这似乎是一个合理的折衷方案，但是它充满了使用户感到沮丧的问题.首先，没有简单的方法将需要访问权限的用户排队编辑记录. Sarah可以尝试10次，然后经过10分钟，Jimmy访问了该页面，由于他是锁到期后的第一个人，因此他抓住了下一把锁，而Sarah没有机会.萨拉(Sarah)致电您的服务台，说她等了10分钟才能使锁失效，现在已经15分钟了，她仍然无法进入页面.您的服务台可能会怀疑她真的等了整整10分钟.

This seems like a reasonable compromise, but it is rife with problems sure to frustrate users. First, there is no easy way to queue up users who need access to edit the record. Sarah could try 10 times, and then just as it passes 10 minutes, Jimmy visits the page and because he was the first person after the lock expired, he grabbed the next lock without Sarah getting a chance. Sarah calls your help desk and says she waited 10 minutes for the lock to expire, and it's now been 15 minutes and she still can't get to the page. Your helpdesk probably doubts she really waited a full 10 minutes, back and forth ensues.

您还必须为当前拥有锁的任何人实现客户端计时器/显示，以便他们知道在锁到期之前还剩下多少时间.

You also must implement a client side timer/display for whoever currently has the lock so they know how much time they have left before it can expire.

在大多数情况下，这是正确的方法.实际上，您根本不会以任何方式锁定记录.相反，许多用户可以访问编辑页面.当他们保存编辑时，表单将同时包含原始值和新编辑的值.服务器会将表格中的原始值与数据库中的当前值进行比较，以查看是否存在临时编辑.

This is the right approach in most cases. You don't actually lock the record in any way at all. Instead, many users can visit the edit page. When they save an edit, the form includes both the original values and the new edited values. The server will compare the original values from the form, with the current values in the database, to see if there was an interim edit.

原始值是从过去某个时间开始的(Bob最初访问编辑页面时). 当前值是现在的值.在过去和现在之间，如果Sarah也访问了编辑页面，并成功保存了对数据库值的更改，则Bob的原始值将与数据库.因此，当Bob尝试保存更改时，服务器将看到他的原始值与数据库中的当前值不同，并引发错误.您将需要决定如何处理这种情况.通常，您让用户知道其他人自此以来已经编辑了该页面，然后刷新页面，他们会丢失其编辑内容.实体框架支持乐观并发.

The original values are from some point in the past(when Bob initially visited the edit page). The current values are from right now. Between the past and now, if Sarah also visited the edit page, and successfully saved changes to the database values, then Bob's original values will be different from the current values in the database. Thus when Bob attempts to save his changes, the server will see that his original values are different than current values in the DB, and throw an error. You will need to decide how you handle this situation. Usually you let the user know that someone else has edited the page since they did, and refresh the page, and they lose their edits. Entity Framework supports optimistic concurrency.

您还可以让客户端偶尔用原始值对服务器执行ping操作，以便服务器可以检查您的页面是否陈旧(即其他用户更改了某些内容)并弹出一条消息.通过提前通知用户另一个用户已经编辑了页面，从而改善了用户的体验.因此，他们在进行编辑时不会走得太远，而无论如何它们都会丢失.他们还可以从浏览器中记录/复制/粘贴其编辑内容，从而可以刷新页面并参考更改内容.

You can also have the client occasionally ping the server with original values so the server can check to see if your page is stale(i.e. other user changed something) and popup a message. This improves the user's experience by giving the user earlier notice that another user has edited the page. Thus they don't get to far along in making edits which they are going to lose anyways. They can also take note/copy/paste their edits out of the browser so that can refresh the page and have a reference of what they changed.

SQL Server中有一个时间戳记"列，该列可以与Entity Framework协同工作，以降低检查更改所涉及的开销.这样您就不必在每个客户端中保留原始值的完整记录并将它们传回:

There is a Timestamp column in SQL Server which can work in tandem with Entity Framework to lower the overhead involved in checking for changes. Such that you don't need to keep the entire record of original values in each client and pass them back in forth: http://www.remondo.net/entity-framework-concurrency-checking-with-timestamp/

我们大量使用的一种方法是将每个字段都合并起来，并立即提交对单个字段的编辑.这是使用称为x-editable的jquery库完成的.用户编辑单个字段，确认编辑，然后将该值发送到服务器.如果要检查整个记录的更改，或者仅检查单个字段，可以将其与乐观并发结合使用.如果检测到更改，则您拒绝编辑并刷新页面.对于用户而言，这可能是更友好的体验，主要是因为在编辑单个字段时，用户会立即收到另一个用户编辑过的页面"错误.这样可以避免他们浪费大量时间来编辑大量字段，而只是发现他们的编辑被拒绝了，因此他们不得不再次重做所有编辑.相反，他们只编辑一个字段，得到错误，刷新页面，他们只需要重复一次该字段的编辑并从那里继续.

One approach we use alot is to ajax'ify every field and edits to a single field are committed immediately. This is accomplished using a jquery library called x-editable. The user edits a single field, confirms the edit, and that value is sent to server. You could combine this with optimistic concurrency if you wanted to check the entire record for changes, or just the single field. If changes are detected, then you reject the edit and refresh the page. This can be a much friendlier experience for the user, primarily because the user gets the "Another user edited page" error instantly when editing a single field. This prevents them from wasting alot of time editing a large number of fields, only to find their edit was rejected and they have to redo all of their edits again. Instead, they edit a single field, get the error, page refreshes, they only have to repeat that one field edit and continue from there.

http://vitalets.github.io/x-editable/demo- bs3.html

这篇关于asp.net mvc;一次仅适用于一个用户的编辑选项的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！