asp.net core ef 如何防止重复（add）提交？

[boyyao]

看了下ef的用法。似乎针对update/edit。可以用
[ConcurrencyCheck] 或者 RowVersion 来防止并发提交修改的问题。。

但是针对数据的ADD方法呢？如何用优雅的方法防止重复的提交？
比如用户有个post表

代码中用User.Post.Add(new Post{"xxxxx"})
用户通过用postman等方法重复提交如何处理？用lock(obj)？
假设模型大概如下：
public class User
{
[ConcurrencyCheck]
public string UserName { get; set; }

public List<Post> Post { get; set; } = new List<Post>();
}

public class Post
{
public string data { get; set; }
}

[jhdxhj]

防重复提交与EFCORE没有什么关系

[jhdxhj]

你可以提交完了之后，页面刷新或者提交按钮置灰

[正怒月神]

我都是 过滤器，进行幂等验证的。 简单一点，就是提交的数据md5，缓存10秒。 每次提交数据，去匹配缓存里的md5数据是否存在。

[boyyao]

之前也尝试过用IPageFilter或者IActionFilter 来过滤重复的单个url的post请求。但是有时候会有如下情况： 一个页面有两个按钮。分别增加不同的记录。但是这两个不管提交多块只要保证每个按钮只提交一次。 就会导致快速的点了a和b的合法用户也遭到了过滤。(不一定是两个按钮，也可能是两个选项？) 而每条提交的数据做md5然后cache感觉有点麻烦。。也难免会有遗漏。。 不知道ef有没有类似的Filter？比如我在add操作之前注册一个过滤器。检查前后两条记录是否相同？

[圣殿骑士18]

为什么要让EF来做这个缓存呢？这不是糟蹋EF吗。EF是技术框架，你一个业务需求，让EF来给你负责，显然是职责不清。你要过滤，自己前置一个过滤器不就行了，这跟前面那位10s的md5验证没本质差别，他不也过滤器么。

[圣殿骑士18]

EF会有ConcurrencyCheck和RowVersion的方案，是因为前端所有的防范，都无法完全避免数据库端的修改冲突，所以EF需要出这个方案。 而你这个add重复问题，前端就很好解决的。到不了后头。

[快乐起航2020]

jq one方法，或者提交成功的时候，让按钮变成不可用

[墨子宸]

搞个全局变量状态判断，像微信小程序那样，前端可以搞定的事情就不要往后走了

[以专业开发人员为伍]

“糟蹋EF”这个说法我非常同意。许多好的 .net 框架都被增加了 80% 的框架，例如命名的高速基于内存的分布式 Actor 模型框架却要自身一定要包含什么增删改查数据后备功能（而不是为其“创建”和“持久化”两个功能提供接口来适配其它系统），结果造成初学者一开始就开始反复比较反复“研究”最终因为根本就不属于其核心的价值功能而放弃它。

你可以在各方面各层次去做业务逻辑。例如数据库中可以给“发票”以唯一编号，并且在前端“填写发票”时传送这个发票号占用和填写信息，用户可以一边填写发票，你的程序可以随时保存（持久化）状态信息。用户可以废掉这张发票，也可以填写另外一个发票（使用另外一个发票号）。

许多业务就如我上面所说，是基于 Actor 来设计的。用传统的说法就是“面向对象”来设计的，也就是说管理信息的第一位的概念是“对象唯一性”。例如一个“发票系统设计师”他心理把发票当作一个在网络上独立存在的实体，围绕这个实体有生命周期。而那些满眼只有“面向过程”的人心中没有对象的生命周期概念，自然也就处理不了稍微复杂一点，稍微涉及到对象生命期的程序。

[以专业开发人员为伍]

纠结单纯“编程技术”问题是看不到出路的。真正好的程序员，都是从工程设计，从技术之外，已经解决了这类问题。

[以专业开发人员为伍]

上面说到数据库模式和业务逻辑设计来帮助进行业务设计，要从更高层面的“技术”设计原理来说明一下现在更加注重什么网络设计模式。

现代的网络高性能高并发“大数据”的系统的技术瓶颈，真正的高性能高并发系统，首先是“不落地”的各种功能设计为核心，是基于通讯技术和缓存技术，而不是基于数据库的。数据库只是数据落地的后备。假设一个系统有10台服务器，那么在服务器内存中可能有5千万高速缓存着的对象，这些对象高并发地处理各自的业务，对任意对象的访问可以自动路由到不同的服务器。例如一个系统上有1亿张发票信息，当一个发票信息被1天之内重复处理了1万次，那么9900次都是在缓存中直接找到发票对象，直接在服务器上处理。当发票对象从网络服务系统高速缓存中丢失之后，下次使用时就会自动在另外一台服务器的高速缓存中“重建”这个对象并从数据库后备中重新加载状态。而另外一些服务器系统，则可能根本不用任何磁盘存储数据库，而是通过在网络上的多台服务器内存中重复备份多份信息来保证“不丢失”数据。

[ying1234]

引用 11 楼 以专业开发人员为伍 的回复:

上面说到数据库模式和业务逻辑设计来帮助进行业务设计，要从更高层面的“技术”设计原理来说明一下现在更加注重什么网络设计模式。 现代的网络高性能高并发“大数据”的系统的技术瓶颈，真正的高性能高并发系统，首先是“不落地”的各种功能设计为核心，是基于通讯技术和缓存技术，而不是基于数据库的。数据库只是数据落地的后备。假设一个系统有10台服务器，那么在服务器内存中可能有5千万高速缓存着的对象，这些对象高并发地处理各自的业务，对任意对象的访问可以自动路由到不同的服务器。例如一个系统上有1亿张发票信息，当一个发票信息被1天之内重复处理了1万次，那么9900次都是在缓存中直接找到发票对象，直接在服务器上处理。当发票对象从网络服务系统高速缓存中丢失之后，下次使用时就会自动在另外一台服务器的高速缓存中“重建”这个对象并从数据库后备中重新加载状态。而另外一些服务器系统，则可能根本不用任何磁盘存储数据库，而是通过在网络上的多台服务器内存中重复备份多份信息来保证“不丢失”数据。

P哥高见。

[a@serfend]

/// <summary> /// avoid duplicate /// </summary> [Key] public string YourField { get; set; }