我在 cmets here (current live site, without comments) 中阅读了一场辩论。
为什么要辩论？对我来说，数据集就像一个关系数据库，一个对象是一个类似层次结构的模型。为什么人们绝对想要一个“纯”对象模型，而我们仍然处理关系数据库，那么为什么不将两者结合起来呢？
如果我们应该这样做，是否有任何轻量级、综合性的框架可以让我们做到这一点（而不是像 NHibernate 这样具有巨大学习曲线的笨重的庞然大物）？
【问题讨论】：
“纯对象”更容易使用，类型化对象为您提供智能感知和编译时类型检查。
使用裸数据集非常麻烦且烦人 - 您需要知道列名，无法进行类型检查，因此如果您输入错误的列名，您就很不走运了，直到您才发现错误运行时（最坏的情况）。
类型化数据集是朝着正确方向迈出的一步，但是您在 .NET 代码中使用的“事物”仍然与您的数据库实现紧密相连——这通常不是一件好事，因为底层的任何变化数据库可能会影响您的应用程序直至您的 UI，并导致需要进行大量更改。
使用像 NHibernate 这样的 ORM 可以让您更好地将数据库（物理存储）层从逻辑业务模型中抽象出来并解耦 - 只有在最简单的场景中，这两者才能精确地 1:1 匹配，所以您需要无论如何，两者之间存在某种“翻译”或映射。
总而言之，对于小型、简单的应用程序来说，使用类型化数据集可能没问题，但对于具有挑战性的、大规模的企业级业务应用程序，我绝不建议将您的业务对象模型如此紧密地耦合到数据库。
马克
【讨论】：
为什么人们绝对想要“纯”对象模型
因为您不希望您的应用程序依赖于数据库架构
【讨论】：
嗯，您给出的所有理由都与过去为 Java 中的 EJB 提供的学术理由相同，这在过去是一团糟。那么人们不是又陷入了另一种时尚炒作吗？
正如我在这里读到的： http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
承诺是一回事，现实是另一回事。
索赔的证据在哪里？
从科学上讲，复杂性与熵的概念紧密相关，你不能降低事物固有的复杂性，你可以把它移到其他地方，所以对我来说，这从根本上来说是不合理的。
【讨论】：
Ted Newards 备受争议，因为在我看来，每个人都像在旧的 EJB 时代一样从众：在 Rod Johnson 退出 Hibernate 之前，没有人敢说 EJB 很烂。
现在似乎没人愿意说像 Hibernate、Entity Framework 等 ORM 框架太复杂了，因为可能还没有另一个 Rod Johnson II :)
你假装添加一个新层可以解决问题，即使在理论上也并非总是如此，例如当项目变得一团糟时添加更多团队成员，因为添加更多程序员也意味着增加协调和沟通问题。
在实践中，至少从 GUI 的角度来看，应该独立的层实际上并非如此。我看到很多人在使用 ORM 时很难在 GUI 中做一些简单的事情。
【讨论】：