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

Question

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

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

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

Answer 1

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

我认为像“ Entity Framework ”这样的工具不会培养出不了解关系数据库设计原则的一代开发人员。首先也是最重要的是，面向对象设计已经存在了很长时间，人们多年来一直在寻找解决方案来弥合 OO 和 RDBMS 之间的差距。

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

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

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

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