实体编程如何改变我们对数据库的看法？

Posted 2023-04-12

【中文标题】实体编程如何改变我们对数据库的看法？

【英文标题】：How is Entity Programming changing the way we think about databases?

【发布时间】：2009-06-24 23:11:50

【问题描述】：

我想知道从关系型、基于表的设计到面向对象、基于实体的设计的转变如何影响开发人员编写下一波应用程序的心态。

鉴于the debate swirling around the Entity Framework and Linq to SQL 的性质，考虑实体驱动设计是否为时过早？

我们是否正在培养新一代的开发人员，他们不了解关系数据库设计和开发的基本原理，因为他们会被 Entity Framework 之类的工具屏蔽掉？实体框架真的足够聪明，可以为他们做出这些设计决策吗？

【参考方案1】：

嗯，恕我直言，这个问题很难回答。

我不认为像“实体框架”这样的工具会导致培养出一代不了解关系数据库设计原则的开发人员。 首先，面向对象的设计已经存在很长时间了，人们一直在寻找解决方案来弥合 OO 和 RDBMS 之间的鸿沟。

我看不到您所说的“实体驱动设计”（我宁愿称其为域驱动设计），而是替换关系数据库设计。事实上，对我来说，这两件事将继续并存，因为这两种技术都是-恕我直言-他们试图解决的问题的最佳解决方案： - OO 是建模数据 + 行为的完美方式 - 关系模型是有效存储数据并在其上运行查询的完美方式。

如果您想成功地以领域驱动的方式创建应用程序（使用像 NHibernate 或实体框架这样的 O/R 映射器），您（开发人员）仍然需要对以下方面有基本的了解和知识关系模型是如何工作的。 事实上，您仍在与关系数据库通信，尽管是通过 O/R 映射器。 例如，如果您想要一个性能良好的应用程序，则必须知道关系数据库是基于设置的；执行 SELECT n + 1 查询等不是一个好主意...

事实上，我使用 O/R 映射器 (NHibernate) 已有一年（专业），并且我已经使用它几年了，但我仍然更喜欢手动创建我的关系数据模型.我不会通过我编写的类通过我的 O/R 映射器生成我的数据库模型，因为我想控制。

如此简短的回答：我认为如果开发人员想要成功使用 O/R 工具，他仍然需要了解关系模型。

【参考方案2】：

好问题。

首先，我认为我们还没有完成。实体框架和它的同行是进入实体驱动设计的一些很好的早期步骤。但在设计我们的软件解决方案时，我们肯定远没有将技术视为理所当然。

至于你的第二点。

我们是否正在培养新一代 不懂的开发者 关系的基本原则 数据库设计和开发， 因为他们会被屏蔽 他们通过实体之类的工具 框架？

将当前软件开发中最痛苦的部分之一封装在日常开发人员之外会是一件坏事吗？当高阶语言开始吸引开发人员远离 c++ 时，我认为它与内存管理非常相似。这是否意味着您可以忘记内存管理？不，一点也不，但你不必像以前那样专注于它。留出更多的大脑周期来专注于软件的业务问题。如果可能的话，我期待着有一天我可以用我的持久性模型做同样的事情。