您在数据访问层中实施和维护简单的创建，读取，更新和删除（CRUD）方法所花费的总开发工作的百分比是多少？
迁移到像Hibernate或Entity Framework这样的ORM会导致显着的节省吗？ 是否有任何设计气味让您知道何时转移到ORM，您的数据访问层是一个不错的选择？
亲切的问候， 阿希什
答案 0 :(得分：5)
最近花了数小时（可能大约40％）重复ORM在几分钟内完成的工作，我不得不说，只要你能让经过良好测试的框架生成（并维护！）基本的CRUD运营，让它做到！
让框架做到它擅长的那个。花时间在应用程序的一部分，真正增加价值，你正在解决的业务问题。只有当框架不足时，你才真正考虑解决它。 “落空”可能包括性能，但通常在框架内有“钩子和旋钮”，让你做你需要完成的事情。
实现/设计气味：当您第40次编码'StoredProcedureWrapper'或通过捕获DAO输出实现查询结果的缓存时，您可以/应该使用ORM
使用Ruby / Rails或Groovy / Grails类型的框架，我无法看到 NOT 开始使用ORM层的真正原因，因为两个环境都为您生成域。
使用Spring / Hibernate，它有点复杂，但仍然可以节省大量非常相似的小类的手动编码。
我在过去10年左右的几个项目中也发现，如果我们没有开始使用ORM，我们最终开发或“窃取”JDBC框架或其他脚手架代码，这些代码再次重复了很多内容ORM可以帮到你。