覆盖实体框架中的行为

Question

我们有一个有一些要求的数据模型。我想找到一种方法，使这些要求在使用EF时尽可能透明。

首先，模型必须支持软删除。我已经看到了一些关于这个的问题，我认为这是相对简单的。

其次，我们有一个“仅插入”政策。这意味着没有更新。进行更新时，必须插入新条目。我希望能够将操作视为更新，并让框架将其更改为幕后插入。

第三，由于我们查询时＃2，我们需要通过降序标识列进行排序并仅返回第一条记录。即使在执行返回许多记录的查询时也是如此。从本质上讲，这会创建一个版本历史记录。

第四，我们不希望在每个查询中实现此逻辑。让框架为我们做这件事会很好，所以我们可以将每个查询视为普通的CRUD类型事务。

有没有人在EF中实现过这样的数据模型？你用了什么技术？

我知道其中一些可以在Views和/或Sprocs中完成，但如果你使用视图，那么你必须手动维护所有关系（EF无法通过视图读取关系）。触发器也是可能的，但是我们的DBA希望尽可能少的触发器，并且对所有需要很长时间才能完成的触发器进行非常广泛的审查策略。如果我不需要，我宁愿不使用触发器。

我主要使用数据库第一种方法，但我使用dbcontext。

编辑：

鉴于Ladislav的评论如下，我也对任何可能能够满足这些要求的ORM的评论感兴趣。

Answer 1

1. 这可以通过条件映射实现，其中将使用附加列来区分已删除的记录，并为需要软删除的每个实体执行更新而不是删除的custom SQL command /映射存储过程。
2. 我怀疑EF会透明地处理这个问题。如果修改从数据库加载的附加实例，它将执行更新。您可以再次映射存储过程以执行插入而不是更新，但该更改不会反映在您的应用程序逻辑中。您必须使用新的上下文实例处理上下文并重新加载数据才能正确查看更改。更好的选择只是强制你的应用程序在某处克隆实体并将克隆插入一个新的。
3. EF不允许您透明地向自动生成的查询添加此类条件，除非您将其映射为视图或custom SQL query。使用视图或SQL查询后，还必须使用插入，更新和删除操作中的SQL命令或存储过程。使用自定义SQL查询与使用视图具有相同的缺点。
4. 如果您不使用SQL查询，则必须自己编写查询，例如以自定义可重用扩展方法的形式，并在任何地方使用它，但要注意，急切或延迟加载不会反映这一点。如果需要热切和延迟加载，您将始终获得所有版本。

存储过程映射需要EDMX。自定义SQL命令和查询映射需要EDMX，没有任何其他商业工具，您还必须手动维护EDMX。