应该/我可以将实体框架用于非标准 CRUD 吗？

Question

我正在编写一个应用程序，其数据库的架构略有不同。至少我认为这很不寻常，我很少做 DB 的东西。

我所有的书都告诉我应该使用实体框架（或其他一些 ORM）来访问数据库，但他们给出的示例总是沼泽标准 CRUD。每个实体一个表，每个对象一行，活动记录等。

我的架构使用不相交的子类型，因此每个实体有多个表，并且具有修订历史记录，因此编辑实际上会创建一个新行，但仅在一个表中（取决于已编辑的字段）

EF 是迎合这种自定义行为还是面向传统模式？我的理解是我创建了一个模式或域对象，数据库操作代码是自动生成的。我可以覆盖默认行为吗？我还能如何告诉 EF 我的自定义行为？

如果 EF 能让我的生活变得更轻松，我非常愿意学习它，但我不想花很多精力去学习一个我最终会努力让它发挥作用的框架我想要。如果是这种情况，我宁愿推出自己的存储库并自己处理 SQL。

Answer 1

这个问题太抽象，无法明确回答。 EF 提供了一些高级映射方案，其中可以将更多表映射到单个实体，但它定义了严格的规则来实现这一点。或者，您可以映射数据库视图或自定义 SQL 查询，结合表中的数据来形成实体。

更复杂的是您的第二个要求 - 它通常需要编写您自己的 SQL / 存储过程并将其映射到对表执行的 EFs CUD 操作。此 SQL 代码将包含您的更新规则的一部分，因为 EF 更新整个实体不仅影响记录。如果您使用映射视图或查询，则必须将这些 CUD 操作映射到自定义 SQL 或存储过程，否则您的实体将是只读的。

结论：可以实现你想要的，但并不简单，需要高级的EF知识，你还是会写一些SQL。