Orm 实体框架中的重写行为

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

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

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

第三，当我们查询时，由于#2，我们需要在identity列上降序并只返回第一条记录。即使在执行返回许多记录的查询时也是如此。本质上，这会创建一个版本历史记录

第四，我们不想在每个查询中都实现这个逻辑。最好让框架为我们做这件事，这样我们就可以将每个查询当作一个普通的CRUD类型事务来处理

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

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

我主要使用数据库优先的方法，但我使用dbcontext

编辑：

鉴于Ladislav在下面的评论，我也对其他能够处理这些需求的ORM的评论感兴趣

这在条件映射中是可能的，在条件映射中，对于每个需要软删除以执行更新而不是删除的实体，将使用附加列来区分删除的记录和/或映射的存储过程

我怀疑EF是否会透明地处理这件事。若修改从数据库加载的附加实例，它将执行更新。您可以再次将存储过程映射为执行insert而不是update，但该更改不会反映在应用程序逻辑中。您必须处理上下文并使用新的上下文实例重新加载数据，才能正确查看更改。更好的选择是简单地强制应用程序在某处克隆实体，并将克隆作为新实体插入

EF将不允许您透明地将此类条件添加到自动生成的查询中，除非您将其映射为视图或视图。使用视图或SQL查询后，还必须从insert、update和delete操作中使用SQL命令或存储过程。使用自定义SQL查询与使用视图具有相同的缺点

如果您不使用SQL查询，您将不得不自己编写查询，例如以自定义可重用扩展方法的形式编写查询，并在任何地方使用它，但请注意，即时或延迟加载不会反映这一点。在急加载和延迟加载的情况下，您将始终获得所有版本

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

这在条件映射中是可能的，在条件映射中，对于每个需要软删除以执行更新而不是删除的实体，将使用附加列来区分删除的记录和/或映射的存储过程

我怀疑EF是否会透明地处理这件事。若修改从数据库加载的附加实例，它将执行更新。您可以再次将存储过程映射为执行insert而不是update，但该更改不会反映在应用程序逻辑中。您必须处理上下文并使用新的上下文实例重新加载数据，才能正确查看更改。更好的选择是简单地强制应用程序在某处克隆实体，并将克隆作为新实体插入

EF将不允许您透明地将此类条件添加到自动生成的查询中，除非您将其映射为视图或视图。使用视图或SQL查询后，还必须从insert、update和delete操作中使用SQL命令或存储过程。使用自定义SQL查询与使用视图具有相同的缺点

如果您不使用SQL查询，您将不得不自己编写查询，例如以自定义可重用扩展方法的形式编写查询，并在任何地方使用它，但请注意，即时或延迟加载不会反映这一点。在急加载和延迟加载的情况下，您将始终获得所有版本

---

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

在#4，您似乎希望在特定实体上实现这一点，而不是在每次查询的基础上，对吗？所以它应该是实体类的可配置属性？@GertArnold-我不理解你的问题。实体是POCO的，因此它们不控制用于填充它们的查询逻辑。我以为您希望某些类具有定期更新，而某些类具有经审核的“仅插入”更新（在任何地方配置）。可能不会。在#4，似乎您希望在特定实体上实现这一点，而不是在每个查询的基础上，对吗？所以它应该是实体类的可配置属性？@GertArnold-我不理解你的问题。实体是POCO的，因此它们不控制用于填充它们的查询逻辑。我以为您希望某些类具有定期更新，而某些类具有经审核的“仅插入”更新（在任何地方配置）。可能不会，那太不幸了。您知道有其他更适合此场景的ORM吗？nHibernate能处理这件事吗？并没有涵盖所有内容，但仍然很有趣：这很不幸。您知道有其他更适合此场景的ORM吗？nHibernate能解决这个问题吗？虽然没有涵盖所有内容，但仍然很有趣：