architecture - n 层系统是否为大型数据集处理生成 "sense"？

Question

我最近成为编写我们“旗舰”产品的开发团队的一员。它主要是在 N 层系统中实现的读取密集型 Web 应用程序(asp.net(c#) 和 oracle)。数据库中的大部分写入都是通过外部服务完成的(而不是通过 webapp)。他们没有在数据库中安排正常的批处理作业以进行数据聚合，而是将所有内容向上推送到业务层(有时会创建一亿个对象)。虽然这确实将所有“业务逻辑”保留在同一个地方，但它也比在数据库中运行等效查询要长约 200 倍。这对我来说似乎是一个可怕的想法。我在这里错了吗，这是标准的好东西吗？有没有人有任何真实的案例研究可以让我的同事(或者我自己，如果我错了)？

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

Answer 1

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

最佳实践是聚合尽可能接近的数据，最好是在数据库中。一亿个物体似乎很疯狂。

但是，我们都知道这样代码的可维护性较差。因此，最终会花费更多的开发时间和更多的成本。

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

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

也许正确的平衡需要两者兼而有之。例如，对于良好的投资返回率:

对数据库的查询可以进行第一级聚合，去掉微小的细节，并将要创建的对象数量减少 100 个。

业务层可以应用其余规则

是什么使查询中的需求成为一个很好的候选者:

减少离开数据库的对象(或行)数量的低级别聚合

很少改变的规则

在 SQL 中易于阅读的规则

To make your code more explicit (and reduce duplication between queries), I suggest that your code adopts a compile-time structure that makes it clear. Create explicit constants or functions that embody each business rule that you will put in a query, and use that to build (at runtime or compile-time) your queries.