我目前正在研究高度可维护系统的应用程序设计的最佳实践（在相当高的水平），这导致最小的摩擦变化。 “数据层”是指数据库设计，对象关系映射器（ORM）和通用数据访问技术。
根据您的经验，您发现了什么是常见的错误＆amp;在数据层开发方面的不良做法以及您采取/采取了哪些措施/或者可以建议从开发人员的角度使数据层成为更好的地方？
示例答案可能包括：缓慢，可扩展性差且可扩展的数据层最常见的原因是什么？ +可以采取哪些措施（无论是设计还是重构）来解决这个问题？
我正在寻找这里的战争故事和一些现实世界的建议，我可以将其纳入公开的指导文件和样本中。
答案 0 :(得分：1)
魔术。
我使用了Hibernate，它自动存储和提取数据库中的对象。它还支持延迟加载，因此只有在您请求时才从数据库中检索相关对象。这是以我不理解的神奇方式运作的。
这一切都可以正常工作，但是当它发生故障时，无法追踪它。我认为当我们将Hibernate与AOP结合起来时我们遇到了一个问题，当我们的代码被执行时，Hibernate尚未初始化该对象。这个问题很难调试，因为Hibernate以如此神秘的方式工作。
答案 1 :(得分：0)
对象 - 关系映射是不好的做法。通过这种方式，我的意思是它倾向于生成只能被松散地描述为“关系”的数据模式，因此它们的扩展性很差并且数据完整性很差。
这是因为正确的关系模式已经过标准化过程，而O-R Mapping的结果通常是作为数据库表实现的对象类。这些通常不会被标准化，而是为了方便OO开发人员而设计。
当然，在持久数据要求最低的情况下，这并不重要。
然而，我曾经为一家通过收购其他几家公司而成长的航运公司工作，并将一个综合运营系统的开发外包（以替换它继承的各种公司特定系统）给一家使用OO的公司方法，使用OR映射生成的数据模式。正在开发的系统的性能特征非常差，并且数据模式如此复杂，以至于运输公司在经过两年的开发之后就将其丢弃了 - 甚至在它开始运行之前！
这是O-R映射的直接结果;模式中最糟糕的复杂性（以及由此导致的性能不佳）是由于存在仅仅作为OO设计过程的工件而创建的表 - 它们反映了屏幕布局，而不是数据关系。