用于将项列表持久化到DB-In代码或SQL的同步逻辑
本文关键字：SQL 同步 代码 DB-In 列表 持久化 用于 | 更新日期: 2023-09-27 18:21:57
我在UI中显示了一个项目列表。它们的形式如下：名称（下拉列表），属性1名称的作用是作为一个唯一键来标识一个唯一项（主键）。
这些值显示在列表中，用户可以选择创建、更新属性并从列表中删除值
现在假设用户删除了属于UI中某一行的一些项目，然后添加了属于相同名称的新项目
然后，用户按下保存以获取的整个项目列表
现在，为了实现这种情况下的持久性逻辑，我有多种选择：
- 我在SQL级别执行所有业务逻辑我必须确保数据库中没有输入重复的名称，所以我在数据库级别通过编写SQL查询来处理这一问题，即查询首先检查是否存在类似名称的条目，如果存在，则更新其他插入项
- 我在代码级别执行业务逻辑，即在保存、比较和同步匹配项时再次重新加载所有数据，然后决定必须插入某些项并删除其他项
- 我在每个项目上都维护一个IsDirty标志，当客户端发生任何更改时，我会更新IsDirty，任何标记为IsDirty的项目都必须更新，添加的任何新项目都必须在SQL级别检查是否存在重复名称。但这种方法的不同之处在于，我们不必从数据库中重新加载数据
- 我从数据库中删除所有项目，并重新插入UI中的所有项目（我想这是最糟糕的方法）
我应该选择哪个选项，为web应用程序保留项目列表的最佳实践是什么？
同步逻辑应该去哪里？
明智的做法是在数据库级别设置一些同步逻辑，并检查名称是否存在，是否不插入，而只是更新？
这个逻辑应该存在于SQL级别还是代码级别（如Java或C#级别）？
这个有名字（设计模式）吗？
@SeaHorse：正如你所提到的，第4项是世界上最糟糕的。。所以请毫无疑问地忽略这个选项。
如果我需要做出决定，我会选择1）方法，在数据库端创建CRUD存储过程，并在域上创建只调用存储过程的逻辑。使用这种方法，如果需要重构某些内容，可以避免打开域代码，而是可以快速对存储过程执行代码更新，这些存储过程是更模块化和可管理的组件。