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

对于大型数据集处理,n层系统是否具有“意义”?

n-tier architecture

3

rfusca · 技术社区 · 15 年前

我最近成为了开发人员团队的一员,他们正在编写我们的“旗舰”产品。它主要是一个在n层系统中实现的读密集型Web应用程序(ASP.NET(C)和Oracle)。数据库中的大多数写入操作都是通过外部服务完成的(而不是通过webapp)。与在数据库中为数据聚合安排常规的批处理作业不同,它们把所有的工作都推到了业务层上(有时会创建1亿个对象)。虽然这确实使所有“业务逻辑”保持在同一个位置,但它也比在数据库中运行等效查询花费大约200倍的时间。这对我来说是个可怕的主意。我错了吗?这是标准的好东西?有没有人做过真正的案例研究,我可以把我的同事引向(如果我错了,我也可以引向自己)?

我不是在争论n层是好是坏,但它是否适合数据聚合处理等?

1 回复 | 直到 15 年前

1

KLE rslite 15 年前

您对处理时间(以及资源,如内存)的看法是正确的。

最佳实践是聚合尽可能接近数据的数据,理想情况下是在数据库中。一亿个物体看起来很疯狂。
然而,我们都知道,这样的代码不易维护。因此,开发时间越长,最终成本越高。

所以你需要达到一个正确的平衡。这不可能从外面传给你,
您必须在项目的特定上下文中仔细权衡优势。 .

例如, 频率所有这一切都很重要。如果这个过程每分钟都发生,那么高成本显然是可以接受的,但是如果它每年都发生,那么很可能不会。

也许正确的平衡需要两者兼而有之。例如,为了获得良好的投资回报率:

对数据库的查询可以进行第一级聚合,去掉微小的细节,并删除一百个要创建的对象的数量。
业务层可以应用其余的规则

在查询中考虑需求的最佳候选条件是什么:

降低从数据库中取出的对象(或行)数的低级聚合
很少改变的规则
在SQL中容易读取的规则

为了使代码更显式(并减少查询之间的重复),我建议您的代码采用一种编译时结构,使其更清晰。创建显式常量或函数,这些常量或函数包含将放入查询中的每个业务规则,并使用它们来构建(在运行时或编译时)查询。