logo标签列表

3层架构模式和大量数据

architecturen-tier-architecture3-tier
5
这是我的情况：我正在尽力遵循三层模式（即表现层、业务层和数据层）。当我需要从数据库获取数据时，业务层调用数据层并返回信息。数据层从不返回SqlDataReader或DataTable对象，但经常返回由数据访问层知道的自定义对象的枚举。当数据层需要返回少量对象列表时，它运行得非常好。
我现在面临的问题是，我的应用程序（业务层）必须处理500,000条记录。我可以简单地向我的数据层添加另一种方法并返回IEnumerable，但这听起来对我来说非常糟糕。我不想在内存中加载50万条记录。
我的问题是，在考虑到三层模型的情况下，我该如何处理这种情况？如果我没有三层模式，我将在我的业务类中简单地使用SqlDataReader。有什么建议吗？
更新：数据不会被显示，因此这不是分页问题（表现层根本没有涉及）。我只需分析每个记录，然后保留其中的一些。
谢谢
9个回答
2

我猜你不会一次性向前端展示50万条记录，对吧？你可能正在进行分页处理，是吗？所以，每次只返回数据库中一页的数据。

1
在数据库中进行过滤。没有必要将你要过滤掉的超过500000条记录全部带到中间层，再将它们删除。尽早使用后端（存储过程）中的SQL引擎处理操作（数据）。这是最有效率的方式，类似于在发送到IIS之前在表示层检查基本输入检查。
1

是的，您的直觉是正确的。

我打赌您的 UI 客户端不想一次查看 50 万条记录。Google 不会在单个页面返回每个结果；您也不会。

您可以选择在何时何地处理这 50 万条记录。您可以将它们划分为更小的工作单元；您可以异步处理它们；您可以编写存储过程，在数据库中处理它们，而不必全部传输到中间层。

MVC 模式很棒，但它不是圣经。做适合您应用程序的选择。

1
一张纸永远无法胜任现实。如果你的具体问题要求打破三层范式，那就去做吧。
1
在某些情况下，您必须打破三层边界。但在此之前，您可以问自己以下问题：

  1. 当您“分析每个记录并保留其中一些记录”时，这真的是业务逻辑的一部分吗？还是数据访问功能？也许这应该属于数据访问层。

  2. 如果它确实是业务逻辑的一部分，您是否需要所有500000条记录才能决定是否“保留”任何单个记录？也许业务层应该一次处理一条记录。连续进行500000个数据库调用并不美观，但如果从概念上来看，这就是应用程序应该执行的操作，那么有方法可以减轻这种情况。

我不建议做任何愚蠢的事情只是为了保持三层分离。但有时，当您认为必须跨越界限时，这是因为设计中有需要重新审视的内容。
-- bmb
1

你可以在SqlReader类之上构建一个抽象层。这样，你就不必直接传递SqlReader，但仍然可以逐个处理对象。

想一下迭代器。

0
这不是一个罕见的问题，在需要合并大量数据并向用户呈现摘要的情况下经常发生（报告是典型的例子）。您的解决方案应考虑到这些因素。如果严格遵循某个特定的体系结构模型会使应用程序效率低下，则忽略SQL读取器（或类似工具）提供的效率是没有意义的。通常可以通过将体系结构模型适应于您的需求来克服其中一些问题。通用的体系结构模型很少能立即适用。它们是指导方针，应该应用于您的特定需求。
0

在数据库层面进行任何分析都没有什么可耻的。如果您可以使用存储过程来切分和处理所需数据，或者使用存储过程进行必要的关联，并使用应用程序进行更复杂的操作，那么您就可以了。

问题是，用户是否希望按下按钮并处理所有 500K 条记录并查看结果？如果是这样，他们是否愿意坐着看旋转的 gif，还是只需在处理完成时收到某种类型的通知即可满足？如果处理这 500K 是最重要的，那么您的数据模型是否需要修改以支持此过程？有一些处理方法，例如 Hadoop 和 message queues，专门针对这种高容量，但您是否需要这样做？在为性能而苦恼之前，您可能需要设定用户的期望值。

0
如果我理解正确的话，您想要“分析”记录，然后保留其中一些并且丢弃其余的。在这种情况下，我认为最好在数据库本身（PL/SQL或T/SQL）中处理此问题。像这样的需求应该是首要任务，而不是架构。由于您不仅仅是显示而是分析，最好在过程本身中完成。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接