代码之家 › 专栏 › 技术社区 › holsee

好的数据层开发和设计:数据层开发中常见的坏做法是什么?

data-tier-applications command-query-separation orm database

0

holsee · 技术社区 · 14 年前

我目前正在研究应用程序设计的最佳实践(在一个相当高的水平上),以实现高度可维护的系统,从而使更改的摩擦降到最低。“数据层”指的是数据库设计、对象关系映射器(ORMs)和通用数据访问技术。

从您的经历中,您发现了哪些常见错误&当涉及到数据层开发时的错误做法,从开发人员的角度来看,您采取了哪些措施/实施了哪些措施/可以推荐哪些措施使数据层成为更好的地方?

一个示例答案可能包括:导致数据层速度慢、可扩展性差和可扩展性差的最常见原因是什么?+可以采取什么措施(无论是在设计还是重构中)来解决这个问题?

我在这里寻找战争故事和一些现实世界的建议,我可以建立在公开的指导文件和样本。

2 回复 | 直到 14 年前

1

Sjoerd 14 年前

魔法。

Hibernate ,它自动从数据库中存储和获取对象。它还支持延迟加载,因此只有在您请求时才从数据库检索相关对象。我不明白这有什么神奇的效果。

AOP ,当我们的代码被执行时,对象还没有被Hibernate初始化。这个问题很难调试,因为Hibernate的工作方式很神秘。

2

0

user359040 user359040 14 年前

对象关系映射是一种糟糕的做法。我的意思是,它倾向于生成只能松散地描述为“关系”的数据模式,因此它们伸缩性差,数据完整性差。

这是因为恰当的关系模式经历了规范化过程,而O-R映射的结果通常是作为数据库表实现的对象类。这些通常不是标准化的,而是为面向对象开发人员的即时便利而设计的。

当然,在持久性数据需求最小的情况下,这并不重要。

然而,我曾经为一家航运公司工作,该公司通过接管其他几家公司而发展壮大,并将集成操作系统的开发(以取代其继承的各种公司特定系统)外包给了一家使用OO方法的公司,该公司使用O-R映射生成的数据模式。正在开发的系统的性能特征非常差,数据模式非常复杂,以至于航运公司在大约两年的开发之后——甚至在投入使用之前就放弃了它!

这是O-R映射的直接结果;模式中最糟糕的复杂性(以及由此产生的糟糕性能)是由仅仅作为OO设计过程的工件创建的表的存在造成的——它们反映了屏幕布局,而不是数据关系。