我知道有很多ORM粉丝，但你如何处理超过300个表的数据库，有些表有超过100个字段？
我见过的大多数示例应用程序只使用了几个字段。在如此大规模的情况下使用ORM是否谨慎？我认为ORM是多余的（为什么在现实数据库中不容易改变时创建另一层？）。
对我而言，对于可能从数据库迁移到可以在多个平台上运行的数据库或应用程序以使用ORM的小型应用程序是有意义的。
否则它似乎无用或只是另一种头痛。
任何想法？
答案 0 :(得分：1)
我在某些项目（Hibernate）中使用过ORM而在其他项目中没有使用过ORM。 ORM限制与所有抽象相同，您放弃了一些灵活性，您必须投资于学习实现的细节。但是，您通常可以获得编码效率，减少重复，集中配置，并获得特定于实现的其他改进。请注意，数据库可移植性并非总是没有效果 - 显然，如果您使用特定于供应商的功能，则无法实现。
您没有提及您的项目是否已实施数据访问。如果你从头开始，那么数据库的大小不应该太关注你，因为ORM实际上应该在效率和减少重复方面为更大的数据库节省更多。但是，如果您正在考虑更换现有的数据访问实施，并且您没有预见到数据库发生了很大变化，那么您的努力几乎肯定会超过其效益。
BTW，我怀疑示例应用程序使用小型数据库，因为它们创建的工作量更少，用户更容易理解这些示例，而不是因为开发人员认为他们的ORM解决方案仅适用于小型数据库答案 1 :(得分：0)
ORM的巨大附加值是业务逻辑开发人员可以专注于与对象而不是数据库表的交互。
即。有时您的业务对象可能非常复杂或使用多个数据库表（即JPA 2.0中的@SecondaryTable）。您不需要知道实体在数据库中的表示方式，以便完成工作。
关系怎么样？作为开发人员，我不需要知道关系是否实现为连接表，外键或其他。我只需要设置适当的面向对象的关联，ORM将为我完成剩下的工作。
我见过很多大型项目（> 50名开发人员）在ORM上工作得很好，甚至在那个时候工具还不如现在这么好和成熟。
您可能希望看到此主题：Is ORM fit for complex projects?