ORM 与在数据库本身内强制实现的许多约束(特别是唯一键约束/主键之外的唯一索引)的现有数据库的兼容性如何？
(通常这些是预先存在的数据库，由许多遗留应用程序共享。但良好的数据库建模实践是在数据库中定义尽可能多的约束，作为对应用程序的双重检查。另请注意，我使用的数据库引擎使用不支持延迟约束检查。)
我问的原因是我研究过的 ORM，NHibernate 和 Linq to SQL，在存在数据库唯一约束的情况下似乎不能很好地支持。例如，删除一行并重新插入具有相同业务键的行会导致外键异常。 (还有一些微妙的、难以避免的示例。)ORM 遵守主键和外键约束，但往往会忽略唯一约束。
我知道有变通办法，例如 NHibernate flush 方法。但是，我觉得这是一个极度漏洞的抽象，并且很难根据关注点分离来设计应用程序。理想情况下，所有对象都可以通过子例程在内存中进行操作，然后主例程可以负责调用以实际同步数据库。这将隔离更新并允许自定义逻辑在所有更新实际提交到数据库之前检查所有更新。
以正确的顺序执行命令非常重要。看我的问题here .尽管如此，我期待对流行的 ORM 中的常见情况有更好的支持。这对于将 ORM 引入现有环境似乎非常重要。
鉴于这些问题，您使用 ORM 技术的经验是什么？
最佳答案
这当然是恕我直言......
ORM 通常将数据库仅视为数据的存储介质，并且旨在维护“O”端而非“R”端的约束/业务逻辑。我还没有看到任何 ORM 产品使用一些更“核心”的关系数据库概念，如备用键、复合唯一索引和独占子类型。从某种意义上说，ORM 使数据库成为二等公民。
可以说我是老式的，但 ORM 似乎很适合读取数据，但对于将数据写回非平凡的关系设计，我总是发现它不够用。我更喜欢通过 SQL 和/或存储过程进行所有更新。
关于database - ORM 和数据库约束，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1107014/