这是我的情况：我试图尽可能遵循3层模式（即演示，业务和数据层）。当我需要来自数据库的数据时，业务层会调用返回信息的数据层。数据层永远不会返回SqlDataReader或DataTable对象，但通常是数据访问层已知的自定义对象的枚举。当数据层必须返回一个包含少量对象的列表时，它工作得非常好。3层模式和大量的数据
我现在正面临这个问题，我的应用程序（业务层）必须处理500000条记录。我可以简单地将另一种方法添加到我的数据层并返回一个IEnumerable，但这个声音对我来说很糟糕。我不想在内存中加载五十万条记录。
我的问题是，考虑到3层模型，我应该如何处理这种情况？如果我没有3层模式，我只需在业务类中使用SqlDataReader。有什么建议么？
更新：数据将不会显示，所以这不是一个分页问题（表示层根本没有涉及）。我只需要分析每条记录，然后保留其中的一部分。
谢谢
我假设你没有一次向前端显示500,000条记录？你可能正在做一些分页，对吧？所以，一次只能从数据库中返回一页数据。
是的，你的直觉是正确的。
我打赌你的UI客户端不想一次查看50万条记录。 Google不会在单个页面中返回每一次点击;你也不会。
您可以选择何时何地应用程序处理这些50万条记录。你可以把它们分成更小的工作单位;你可以异步处理它们;你可以编写一个存储过程并在数据库中处理它们，而不必将它们全部带到中间层。
MVC模式很棒，但它不是神圣的文字。选择适用于您的应用程序的选项。
这不是一个不常见的问题，并且在您需要合并大量数据并向用户显示摘要（报告是一个典型示例）的情况下经常发生。考虑到这些考虑因素，应该设计您的解决方案。当对某些特定架构模型的严格一致性使您的应用程序效率低下时，忽略sql读取器（或类似工具）提供的效率是毫无意义的。通过调整架构模型以满足您的需求，通常可以克服其中一些问题。通用的架构模型很少适用于开箱即用。他们是应该适用于您的特定需求的指导方针。
一张纸永远不会超过现实。如果您的具体问题要求打破三层模式，请执行此操作。
在数据库级别进行所需的任何分析并不令人羞耻。如果你可以使用存储过程切片和切片，或者与存储过程进行必要的关联，并使用应用程序进行更复杂的操作，那么你应该没问题。
问题是，用户是否期望按下按钮并处理所有500K记录并查看结果？如果是这样，他们是否愿意坐下来观看一个旋转的GIF图片，或者当这个过程完成时是否会收到某种类型的通知令人满意？如果处理500K非常重要，那么您的数据模型是否需要更改以支持此过程？有一些处理方法，如Hadoop和message queues，适合这种高容量，但是你需要去这个程度吗？您可以设置您的用户的期望，然后拉动您的表现。
在某些情况下，您必须打破三层边界。但在此之前，你可以问自己：
当你“分析每个记录，然后保存其中的一些，”是业务逻辑的一部分真的？或者它是一个数据访问功能？它可能属于数据访问层。
如果它是是业务逻辑的一部分，你是否需要所有500000条记录才能决定是否“保留”任何单独的记录？这可能是业务层应该一次处理一条记录。进行500000次连续的数据库调用并不好，但如果这是应用程序从概念角度来看应该做的事情，那么有办法来缓解这种情况。
我不建议做任何愚蠢的事情，只是为了保持3层分开。但有时候，当你认为必须跨越界限时，这是因为设计中有某些东西需要再次观看。
-
BMB
您可以在SQLReader的类之上构建一个抽象。这样你就不必直接传递SqlReader，但你仍然可以一次处理一个对象。
认为迭代器。
如果我正确理解这一点，你想“分析”记录，然后保留其中的一部分并摆脱其余部分。那么在这种情况下，我认为最好在数据库本身（PL/SQL或T/SQL）中处理这个问题。像这些要求应该是最重要的，而不是架构。既然你不是只显示分析，最好在程序本身。
在数据库中执行过滤。无论如何，您无需再提取超过500000条记录。为什么要把它们全部带到中间层去除它们呢？尽可能早地使用后端的SQL引擎（sproc）来处理操作（数据）。效率最高，类似于在发送到IIS之前检查表示层上的基本输入检查。