为什么我们需要实体对象？[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 改善这个问题 我确实需要就当前接受的企业应用程序设计范例的优点进行一些诚实，周到的辩论。 我不认为实体对象应该存在。 实体对象是指我们倾向于为应用程序构建的典型事物，例如“人”，“帐户”，“订单”等。 我当前的设计理念是： 所有数据库访问都必须通过存储过程来完成。 每当需要数据时，调用存储过程并遍历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等的大力推动。请仔细考虑您的回答，如果我遗漏了一些我我真的很想知道它是什么，以及为什么我应该改变自己的想法。 [编辑] 看来这个问题突然又活跃起来了，所以现在有了新的评论功能，我已经直接对几个答案发表了评论。感谢您的答复，我认为这是一个健康的讨论。 我可能在讲企业应用程序时应该更加清楚。例如，我真的无法评论在某人的台式机或移动应用程序上运行的游戏。 对于几个相似的答案，我不得不在顶部提出一件事：正交性和关注点分离经常被引用为采用实体/ ORM的原因。对我而言，存储过程是我能想到的分离关注点的最佳示例。如果不允许除通过存储过程之外的所有其他对数据库的访问，则只要您维护存储过程的输入和输出，理论上就可以重新设计整个数据模型并且不破坏任何代码。它们是按合同编程的完美示例（只要您避免“选择*”并记录结果集）。 问一个已经从事该行业很长时间并且使用了长期应用程序的人：在数据库运行期间，有多少个应用程序和UI层来去去了？当有4到5个不同的持久层生成SQL来获取数据时，调整和重构数据库有多难？你什么都不能改变！ORM或生成SQL的任何代码将您的数据库牢牢锁定。