我真的需要看一些关于当前接受的设计范式的优点的诚实，深思熟虑的辩论 .
我不相信实体对象应该存在 .
实体对象我指的是我们倾向于为我们的应用程序构建的典型事物，例如“人”，“帐户”，“订单”等 .
我目前的设计理念是这样的：
-
必须通过存储过程完成所有数据库访问 .
-
每当需要数据时，调用存储过程并遍历SqlDataReader或DataTable中的行
（注意：我还使用Java EE构建了企业应用程序，java人员请用等价替换我的.NET示例）
我不是反OO . 我为不同的目的写了很多类，而不是实体 . 我承认我编写的大部分类都是静态助手类 .
我不是在建造玩具 . 我在谈论跨多台机器部署的大型高容量事务应用程序 . Web应用程序，Windows服务，Web服务，b2b交互，您可以为其命名 .
我使用过OR Mappers . 我写了几个 . 我使用过Java EE堆栈，CSLA和其他一些等价物 . 我不仅使用它们，而且还在 生产环境 环境中积极开发和维护这些应用程序 .
我已经得出了经过实战考验的结论，即实体对象正在阻碍我们，如果没有它们，我们的生活将变得如此简单 .
考虑这个简单的示例：您获得有关应用程序中某个页面无法正常工作的支持调用，可能其中一个字段没有像应该的那样持久存在 . 使用我的模型，分配给发现问题的开发人员正好打开3个文件 . ASPX，ASPX.CS和带有存储过程的SQL文件 . 该问题可能是存储过程调用的缺失参数，需要几分钟才能解决 . 但是对于任何实体模型，您总是会启动调试器，开始逐步执行代码，最终可能会在Visual Studio中打开15-20个文件 . 当你走到堆栈底部时，你忘了你开始的地方 . 我们一次只能在头脑中保留这么多东西 . 软件非常复杂，无需添加任何不必要的图层 .
开发复杂性和故障排除只是我抱怨的一个方面 .
现在让我们谈谈可扩展性 .
开发人员是否意识到每次编写或修改与数据库交互的任何代码时，他们都需要对数据库的确切影响进行彻底的分析？而不仅仅是开发副本，我的意思是模仿 生产环境 ，所以你可以看到你现在需要的对象的附加列只是使当前的查询计划失效，而在1秒内运行的报告现在需要2分钟，因为您在选择列表中添加了一个列？事实证明，您现在需要的索引是如此之大，以至于DBA将不得不修改文件的物理布局？
如果让人们通过抽象让物理数据存储距离太远，他们就会对需要扩展的应用程序造成严重破坏 .
我不是狂热者 . 我可以确信我是否错了，也许我是，因为Linq对Sql，ADO.NET EF，Hibernate，Java EE等有如此强烈的推动 . 请通过您的回答思考，如果我遗漏了一些东西我我真的想知道它是什么，为什么我应该改变我的想法 .
[Edit]
看起来这个问题突然再次激活，所以现在我们有了新的评论功能，我直接评论了几个答案 . 感谢回复，我认为这是一个 Health 的讨论 .
我可能应该更清楚我在谈论企业应用程序 . 我真的无法评论一个在某人的桌面或移动应用程序上运行的游戏 .
有一点我必须在顶部提出以回应几个类似的答案：正交性和关注点分离经常被引用作为实体/ ORM的理由 . 对我来说，存储过程是我能想到的关注点分离的最好例子 . 如果您不允许除了通过存储过程之外的所有其他数据库访问，理论上您可以重新设计整个数据模型而不破坏任何代码，只要您保留存储过程的输入和输出即可 . 它们是按 Contract 编程的完美示例（只要您避免“select *”并记录结果集） .
问一个改变任何东西的人！ ORM或生成SQL lock your database in stone 的任何代码 .
30 回答
您可能会在comp.object上找到this帖子 .
我并不是声称同意或不同意，但这很有趣并且（我认为）与这个主题相关 .
@Dan，对不起，那不是我想要的那种东西 . 我知道这个理论 . 你的陈述“是一个非常糟糕的主意”并没有一个真实的例子支持 . 我们正在努力在更短的时间内开发软件，减少人员，减少错误，并且我们希望能够轻松地进行更改 . 根据我的经验，您的多层模型在所有上述类别中都是否定的 . 特别是关于使数据模型成为你做的最后一件事 . 从第1天开始，物理数据模型必须是一个重要的考虑因素 .
实体对象可以促进应用程序层上的缓存 . 祝你好运缓存datareader .
具有与数据存储逻辑分离的域逻辑的应用程序适用于任何类型的数据源（数据库或其他）或UI（web或windows（或linux等））应用程序 .
你几乎陷入了数据库，如果你的公司对你当前使用的数据库系统感到满意，那也不错 . 但是，由于数据库超时发展，可能会有一个新的数据库系统，这个系统非常简洁，是贵公司想要使用的 . 如果他们想要切换到数据访问的Web服务方法（如某些时候的服务导向架构），该怎么办？您可能必须在整个地方移植存储过程 .
域逻辑也抽象出UI，这在具有不断发展的UI的大型复杂系统中更为重要（特别是当他们不断搜索更多客户时） .
此外，虽然我同意存储过程与域逻辑的问题没有明确的答案 . 我在域逻辑阵营（我认为他们随着时间的推移而获胜），因为我相信精心设计的存储过程比精心设计的域逻辑更难维护 . 但这是另一场辩论
对我来说，归结为我不希望我的应用程序关注数据的存储方式 . 我可能会因为这样说而受到打击......但是你的应用程序不是你的数据，数据是应用程序的工件 . 我希望我的应用程序能够根据客户，订单和项目进行思考，而不是像DataSet，DataTables和DataRows这样的技术...因为谁知道这些技术会持续多久 .
我同意总是有一定数量的耦合，但我更喜欢耦合向上而不是向下 . 我可以更容易地调整树的四肢和树叶，而不是改变它的树干 .
我倾向于保留用于报告的sprocs，因为查询确实比应用程序通用数据访问有点麻烦 .
我也倾向于在早期的情况下考虑适当的单元测试，就像没有持久的一列可能不是问题 .
我最近一直在考虑同样的事情;我有一段时间是CSLA的重度用户，我喜欢说“所有业务逻辑（或至少尽可能多的合理可能）封装在业务实体中”的纯洁性 .
我已经看到，在数据库的设计与处理数据的方式不同的情况下，业务实体模型提供了很多 Value ，在许多商业软件中就是这种情况 .
例如，“客户”的想法可能包括客户表中的主记录，结合客户所下的所有订单，以及所有客户的员工及其联系信息，以及一些属性 . 可以从查找表中确定客户及其子项 . 从开发的角度来看，能够作为单个实体与客户合作是非常好的，因为从业务角度来看，Customer的概念包含所有这些内容，并且可能会或可能不会在数据库中强制执行关系 .
虽然我感谢引用“如果您的业务规则不在您的数据库中，这只是一个建议”，我也相信您不应该设计数据库来强制执行业务规则，您应该将其设计为高效，快速和规范化 .
也就是说，正如其他人所说，没有“完美的设计”，工具必须适合这项工作 . 但是，使用业务实体可以真正帮助维护和提高工作效率，因为您知道在哪里修改业务逻辑，而对象可以以直观的方式对现实世界的概念进行建模 .
理论说，高度凝聚力，松散耦合的实现是前进的方向 .
所以我想你正在质疑这种方法，即分离问题 .
我的aspx.cs文件是否应该与数据库交互，调用sproc并理解IDataReader？
在团队环境中，特别是在技术人员处理应用程序的aspx部分的情况下，我不需要这些人能够“触摸”这些东西 .
将我的域名与数据库分开可以保护我免受数据库中的结构变化的影响，这当然是一件好事吗？确保数据库功效绝对重要，所以让那些最优秀的人在一个地方处理这些东西，对系统其他部分的影响尽可能小 .
除非我误解了您的方法，否则数据库中的一个结构更改可能会对应用程序的表面产生很大的影响 . 我看到这种关注的分离使我和我的团队成为可能尽量减少这个 . 此外，团队的任何新成员都应该更好地理解这种方法 .
此外，您的方法似乎主张应用程序的业务逻辑驻留在您的数据库中？这对我来说是错的，SQL非常擅长查询数据，而不是imho，表达业务逻辑 .
虽然有趣的想法，虽然它感觉asp中的SQL只有一步之遥，这来自我糟糕的非结构化asp时代，让我感到害怕 .
问题：如果所有业务逻辑都被困在数据库中，如何处理断开连接的应用程序？
在我感兴趣的企业应用程序类型中，我们必须处理多个站点，其中一些站点必须能够在断开状态下运行 .
如果您的业务逻辑封装在一个很容易合并到各种应用程序类型的域层中，那么我可以构建知道业务规则的应用程序，并在必要时在本地应用它们 .
在将数据库中的域层保留在数据库中时，您必须坚持使用一种类型的应用程序，该应用程序需要对数据库具有永久的视线 .
它涵盖了整个企业应用程序的范围 .
我想为OO和RDB之间的距离问题提供另一个角度：历史 .
任何软件都有一种现实模型，在某种程度上是对现实的抽象 . 没有任何计算机程序可以捕捉到现实的所有复杂性，而程序的编写只是为了解决现实中的一系列问题 . 因此，任何软件模型都是现实的减少 . 有时，软件模型迫使现实减少自身 . 就像你希望汽车租赁公司为你预留任何汽车一样，只要它是蓝色的并且有合金，但操作员不能遵守，因为你的要求不适合电脑 .
RDB来自于将信息放入表中的传统，称为会计 . 会计是在纸上完成的，然后是打卡，然后是计算机 . 但会计已经减少了现实 . 会计迫使人们长期遵循其制度，已成为公认的现实 . 这就是为什么计算机软件用于会计相对容易，会计已经有了它的信息模型，早在计算机出现之前 .
鉴于良好的会计系统的重要性，以及您从任何业务经理那里获得的认可，这些系统已经变得非常先进 . 数据库基础现在已经非常可靠，没有人对将重要数据保存在如此值得信赖的东西中犹豫不决 .
我猜想，当人们发现现实的其他方面比会计更难建模（已经是模型）时，OO必定会出现 . OO已成为一个非常成功的想法，但OO数据的持久性相对不发达 . RDB / Accounting很容易获胜，但OO是一个更大的领域（基本上所有都不是会计） .
我们很多人都想使用OO但我们仍然希望安全存储我们的数据 . 以与受尊敬的会计系统相同的方式存储我们的数据更安全的是什么？这是一个诱人的前景，但我们都遇到了同样的陷阱 . 与RDB行业的巨大努力相比，很少有人考虑过OO的持久性，他们已经从会计的传统和地位中受益 .
Prevayler和db4o是一些建议，我敢肯定还有其他一些我没有听说过，但似乎没有一个人能够获得一半的新闻，比如冬眠 .
对于多用户应用程序，尤其是Web应用程序，甚至似乎都没有认真地将对象存储在良好的旧文件中 .
在我每天努力弥合OO和RDB之间的鸿沟时，我尽可能地使用OO，但试图将继承保持在最低限度 . 我不经常使用SP . 我将仅在看起来像会计的方面使用高级查询 .
当鸿沟关闭时，我会很高兴地被贬低 . 我认为当Oracle推出像“Oracle Object Instance Base”这样的东西时，解决方案就会出现 . 要真正流行起来，它必须有一个让人放心的名字 .
为什么要停在实体对象？如果在企业级应用程序中没有看到实体对象的值，那么只需使用纯函数/过程语言进行数据访问，然后将其连接到UI . 为什么不切掉所有的OO“绒毛”呢？
我认为你只是习惯于编写一种特定的应用程序，并解决某种问题 . 你似乎是从“数据库优先”的角度来攻击这个 . 有很多开发人员将数据持久保存到数据库，但性能不是首要任务 . 在很多情况下，在持久层上放置抽象可以大大简化代码，而性能成本则不是问题 .
无论你在做什么，都不是OOP . 这没有错，它只是不是OOP，将解决方案应用于其他问题是没有意义的 .
埃里克，你死了 . 任何真正可扩展/易于维护/强大的应用程序唯一真正的答案是免除所有垃圾并坚持基础 .
在我的职业生涯中，我遵循了类似的轨迹并得出了相同的结论 . 当然，我们被认为是异教徒并且看起来很有趣 . 但我的东西运作良好 .
应怀疑地看待每一行代码 .
埃里克，
没有人阻止你选择你想要的框架/方法 . 如果您打算使用“数据驱动/存储过程驱动的”路径，那么请务必去寻找它！特别是如果它真的，真的可以帮助您按规范和准时交付您的应用程序 .
需要注意的是（您的问题的另一面），您的所有业务规则都应该存储在存储过程中，而您的应用程序只不过是瘦客户端 .
话虽如此，如果您在OOP中执行应用程序，则适用相同的规则：保持一致 . 遵循OOP的原则，包括创建实体对象来表示您的域模型 .
这里唯一真正的规则是一致性这个词 . 没有人阻止你以数据库为中心 . 没有人阻止你做旧式结构（又称功能/程序）程序 . 好吧，没有人阻止任何人做COBOL风格的代码 . 但是，如果应用程序希望获得任何程度的成功，那么一旦应用程序必须非常非常一致 .
有时，您的应用程序和数据层不是紧密耦合的 . 例如，您可能有电话帐单申请 . 您稍后会创建一个单独的应用程序来监控电话的使用情况，以便a）更好地向您宣传b）优化您的电话计划 .
这些应用程序有不同的关注点和数据要求（即使数据来自同一个数据库），它们也会驱动不同的设计 . 如果让数据库驱动代码，你的代码库可能会导致绝对混乱（在任一应用程序中）和维护的噩梦 .
如果您需要通过负载 balancer 多个Web服务器来扩展应用程序，该怎么办？您可以在所有Web服务器上安装完整的应用程序，但更好的解决方案是让Web服务器与应用程序服务器通信 .
但是如果没有任何实体对象，他们就没有太多可谈的内容 .
我并不是说如果它是一个简单的，内部的，短暂的生命应用程序，你不应该写monoliths . 但是一旦它变得中等复杂，或者它应该持续很长时间，你真的需要考虑一个好的设计 .
这样可以节省维护时间 .
通过从表示逻辑和数据访问中分离应用程序逻辑，并通过在它们之间传递DTO，您可以将它们分离 . 允许他们独立改变 .
非常有趣的问题 . 老实说，我无法证明为什么实体是好的 . 但我可以分享我的观点，为什么我喜欢它们 . 代码就像
并不关心订单来自哪里 - 来自DB，来自Web请求，来自单元测试等 . 它使得此方法更明确地声明它究竟需要什么，而不是采用DataRow并记录它期望具有哪些列以及它们应该具有哪些类型是 . 如果以某种方式将其实现为存储过程，则同样适用 - 您仍然需要将记录ID推送到它，而不必在DB中存在 .
此方法的实现将基于订单抽象，而不是基于它在DB中的呈现方式 . 我实施的大多数此类操作实际上并不依赖于此数据的存储方式 . 我确实理解一些操作需要与DB结构耦合以实现性能和可伸缩性目的，仅根据我的经验，它们并没有太多 . 根据我的经验，经常知道Person有.getFirstName（）返回String，返回地址的.getAddress（），地址有.getZipCode（）等等 - 并且不关心调用哪些表来存储该数据 .
如果你必须处理你所描述的问题，比如当额外的列断点报告性能时，那么对于你的任务，DB是一个关键部分，你确实应该尽可能地接近它 . 虽然实体可以提供一些方便的抽象，但它们也可以隐藏一些重要的细节 .
可伸缩性在这里是有趣的 - 大多数需要巨大可扩展性的网站（如facebook，livejournal，flickr）倾向于使用DB-ascetic方法，当尽可能少地使用DB时，可缓存问题通过缓存解决，特别是通过RAM使用 . http://highscalability.com/上有一些有趣的文章 .
除了抽象和松散耦合之外，实体对象还有其他充分的理由 . 我最喜欢的一件事是使用DataReader或DataTable无法获得的强类型 . 另一个原因是，如果做得好，正确的实体类可以通过使用特定领域术语的第一类构造使代码更具可维护性，任何查看代码的人都可能理解，而不是一堆字段名称的字符串它们用于索引DataRow . 存储过程实际上与ORM的使用正交，因为许多映射框架使您能够映射到sprocs .
我不认为sprocs datareaders可以替代好的ORM . 使用存储过程，您仍然受到过程类型签名的约束和紧密耦合，该签名使用与调用代码不同的类型系统 . 可以修改存储过程以修改其他选项和架构更改 . 在架构可能发生变化的情况下，存储过程的替代方法是使用视图 - 您可以将对象映射到视图，然后在更改它们时将视图重新映射到基础表 .
如果您的经验主要包括Java EE和CSLA，我可以理解您对ORM的厌恶 . 您可能希望了解LINQ to SQL，它是一个非常轻量级的框架，主要是与数据库表的一对一映射，但通常只需要较小的扩展即可成为完整的业务对象 . LINQ to SQL还可以将输入和输出对象映射到存储过程的参数和结果 .
ADO.NET实体框架具有额外的优势，即您可以将数据库表视为彼此继承的实体类，或者将多个表中的列聚合到单个实体中 . 如果需要更改架构，可以在不更改实际应用程序代码的情况下更改从概念模型到存储架构的映射 . 同样，这里可以使用存储过程 .
我认为企业中的更多IT项目由于代码不可维护或开发人员的工作效率低（这可能发生在例如sproc-writing和app-writing之间的上下文切换）而不是应用程序的可伸缩性问题而失败 .
我认为这取决于应用程序的“逻辑”有多复杂，以及您实现它的位置 . 如果您的所有逻辑都在存储过程中，并且您的所有应用程序都在调用这些过程并显示结果，那么开发实体对象确实是浪费时间 . 但是对于对象具有彼此丰富的交互的应用程序，并且数据库只是一种持久性机制，拥有这些对象可能是有 Value 的 .
所以，我认为没有一个通用的答案 . 开发人员确实需要意识到，有时候，尝试过于OO会导致更多问题而不是解决问题 .
我的应用程序中的对象倾向于与数据库一对一关联，但我发现使用Linq To Sql而不是使用sprocs可以更轻松地编写复杂的查询，尤其是能够使用延迟执行来构建它们 . 例如来自于Images.User.Ratings等中的r . 这节省了我尝试在sql中计算出几个连接语句，并且使用Skip＆Take for paging也简化了代码，而不必嵌入row_number和'over'代码 .
我发现你的问题非常有趣 .
通常我需要实体对象来封装应用程序的业务逻辑 . 将这种逻辑推入数据层将非常复杂和不足 .
你会做什么来避免这些实体对象？你有什么解决方案？
一个原因 - 将您的域模型与数据库模型分开 .
我所做的是使用测试驱动开发，所以我首先编写我的UI和模型层，并且模拟数据层，因此UI和模型是围绕特定于域的对象构建的，然后我将这些对象映射到我正在使用的技术数据层 . 让数据库结构决定应用程序的设计是个坏主意 . 在可能的情况下，首先编写应用程序，让它影响数据库的结构，而不是相反 .
我还要添加到Dan's answer，将两个模型分开可以使您的应用程序在不同的数据库服务器甚至数据库模型上运行 .
我真的不确定你认为“企业应用程序” . 但我得到的印象是，您将其定义为内部应用程序，其中RDBMS将被设置为一体，系统不必与任何其他系统（无论是内部还是外部）互操作 .
但是如果你有一个包含100个表的数据库，相当于每个表的4个存储过程，如果只是基本的CRUD操作，那就是需要维护的400个存储过程并且不是强类型的，因此很容易出现拼写错误，也不能进行单元测试 . 当你获得一位新的CTO谁是开源福音传播者并希望将RDBMS从SQL Server更改为MySql时会发生什么？
今天的许多软件，无论是企业应用程序还是产品都在使用SOA，并且对于公开Web服务有一些要求，至少我所参与的软件是这样做的 . 使用您的方法，您最终会暴露序列化DataTable或DataRows . 现在，如果保证客户端是.NET并且在内部，则可以认为这是可以接受的网络 . 但是当客户端未知时，您应该努力设计一个直观的API，在大多数情况下，您不希望暴露完整数据库架构 . 我当然不想向Java开发人员解释DataTable是什么以及如何使用它 . 还有Bandwith和有效载荷大小以及序列化DataTables的考虑，DataSet非常重 .
软件设计没有银弹，它实际上取决于优先级所在，对我而言，它是单元可测试代码和松散耦合的组件，可以很容易地被任何客户端使用 .
只是我的2美分
目前不是很多时间，但只是在我的头顶...
实体模型允许您为数据库（以及其他可能的系统）提供一致的接口，甚至超出存储过程接口的范围 . 通过使用企业范围的业务模型，您可以确保所有应用程序始终如一地影响数据，这是非常重要的事情 . 否则你最终得到的是糟糕的数据，这只是一个简单的邪恶 .
如果您只有一个应用程序，那么您实际上并没有“企业”系统，无论该应用程序或您的数据有多大 . 在这种情况下，您可以使用类似于您所谈论的方法 . 请注意，如果您决定在未来扩展系统，将需要完成的工作 .
以下是您应该记住的一些事情（IMO）：
生成的SQL代码错误（要遵循的例外情况） . 对不起，我知道很多人都认为它从来没有找到过能够生成比我能写的代码效率更高的代码的系统，并且代码通常很简单 . 您还经常会生成大量从未使用过的SQL代码 . 这里的例外是非常简单的模式，比如查找表 . 尽管如此，很多人都会被贬低 .
实体<>表（或者甚至是逻辑数据模型实体） . 数据模型通常具有应尽可能与数据库紧密相关的数据规则，其中可包括关于表行如何相互关联的规则或对声明性RI过于复杂的其他类似规则 . 这些应该在存储过程中处理 . 如果所有存储过程都是简单的CRUD过程，则可以最大限度地减少网络到数据库的往返行程 . 这通常是企业应用程序中最大的瓶颈 .
好问题！
我喜欢的一种方法是创建一个迭代器/生成器对象，该对象发出与特定上下文相关的对象实例 . 通常这个对象包装了一些底层的数据库访问内容，但是在使用它时我不需要知道它 .
例如，
我发现当我有一个庞大的数据集可以正常工作时，这种方法很有效，当正确完成时，它会给我一些相对容易测试的小型瞬态对象 .
它基本上是数据库访问内容的薄外壳，但它仍然允许我在需要时灵活地抽象它 .
@jdecuyper，我自己重复的一句格言“如果你的业务逻辑不在你的数据库中，那只是一个建议” . 我认为保罗·尼尔森在他的一本书中说过 . 应用程序层和UI来来去去，但数据通常会存在很长时间 .
如何避免实体对象？大多数存储过程 . 我还自由地承认，无论您是否打算，业务逻辑都会遍及应用程序中的所有层 . 一定量的耦合是固有的并且是不可避免的 .
我想回答一个类似于你提议的例子的例子 .
在我的公司，我必须为产品构建一个简单的CRUD部分，我构建所有实体和一个单独的DAL . 后来另一个开发人员不得不改变一个相关的表，他甚至重命名了几个字段 . 我必须更改以更新我的表单的唯一文件是该表的DAL .
（在我看来）实体带给项目的是：
Ortogonality：一层中的变化可能不会影响其他层（当然，如果您对数据库做出巨大更改，它会波及所有层，但大多数小变化都不会） .
可测试性：您无需触摸数据库即可测试逻辑 . 这样可以提高测试的性能（允许您更频繁地运行它们） .
关注点分离：在一个大产品中，您可以将数据库分配给DBA，他可以优化地狱 . 将模型分配给具有设计所需知识的业务专家 . 将个别表单分配给在webforms等方面更有经验的开发人员 .
最后我想补充一下大多数ORM映射器支持存储过程，因为这就是你正在使用的 .
干杯 .
有趣的问题 . 几个想法：
如果您的所有业务逻辑都在您的数据库中，您将如何进行单元测试？
不会更改您的数据库结构，特别是影响应用程序中多个页面的结构，是整个应用程序中更改的主要麻烦吗？
我想你可能就这个话题而言"biting off more than you can chew" . 当他称之为“Vietnam of Computer Science”时，泰德·纽瓦德并不轻浮 .
有一件事我可以绝对保证，它会改变任何人的观点，就像在无数其他博客，论坛，播客等上经常证明的那样 .
对于一个有争议的话题进行公开的讨论和辩论当然是可以的，只是这一次已经做了很多次，以至于双方都同意不同意并且只是继续编写软件 .
如果你想进一步阅读双方，请参阅Ted博客上的文章，Ayende Rahein，Jimmy Nilson，Scott Bellware，Alt.Net，Stephen Forte，Eric Evans等 .
我们还应该谈论实体究竟是什么 . 当我阅读这篇讨论时，我得到的印象是，这里的大多数人都在关注Anemic Domain Model意义上的实体 . 很多人都在考虑将Anemic Domain Model作为反模式！
富域模型有 Value . 这就是Domain Driven Design的全部内容 . 我个人认为面向对象是一种克服复杂性的方法 . 这意味着不仅技术复杂性（如数据访问，ui绑定，安全......） but also complexity in the business domain ！
如果我们可以应用面向对象技术来分析，建模，设计我们的业务问题，这对于非平凡应用程序的可维护性和可扩展性来说是一个巨大的优势！
您的实体和表之间存在差异 . 实体应代表您的模型，表格只代表您模型的数据方面！
确实，数据比应用程序的寿命更长，但从David Laribee开始考虑this quote：模型永远......数据是一个快乐的副作用 .
关于此主题的更多链接：
Why Setters and Getters are evil
Return of pure OO
POJO vs. NOJO
Super Models Part 2
TDD, Mocks and Design