奇怪的问题，但我不知道它是否反模式。您的回调应用“深入”是不好的做法吗？
说我有一个web应用程序将呈现1000个记录到一个html表格。
我见过的典型方法是将查询发送到数据库，将记录以某种方式转换为某种抽象状态（例如数组或对象等），并将翻译后的记录放入然后在视图中迭代该集合。
随着记录数量的增长，这种方法会占用越来越多的内存。
为什么不随查询一起发送一个回调，该回调在从数据库中读取每个翻译行时执行操作？这意味着您不需要为视图中的进一步迭代收集数据，因此内存占用空间会缩小，而且您不会对数据进行两次迭代。
这种方法肯定有一些隐含的错误，因为我很少看到它在任何地方使用。这种方法有什么问题？
谢谢。
实际上，这正是一个完善的应用程序应该如何表现。
这种方法没有什么问题，只是不是所有的数据库接口都允许您轻松地完成此操作。
如果我们讨论为另一个社交网络制作10记录，那么如果您可以通过一个已经为您实现的单个调用获取一列哈希或任何其他内容，则不需要混淆回调。
这大致是迭代器模式允许您执行的操作。在很多情况下，这会在应用程序和数据库之间的接口上发生故障。像LINQ这样的技术甚至有可以将代码发送回数据库的解决方案。
这种方法肯定会有一些隐含的错误，因为我很少在任何地方看到它。
我使用它。经常。即使我不会使用太多内存来重复复制数据，使用回调看起来更清晰。在使用闭包的语言中，它还可以让您将相关的代码保存在一起，同时将杂乱的数据库内容分解出来。
这是一个“受工具限制”类的问题：大多数编程语言不允许说“围绕此代码做些事情”。近年来随着关闭的出现，这个问题得到了解决。将闭包看作将代码传递到另一个方法然后在上下文中执行的一种方式。例如，在GSQL，你可以写：
def l = []
sql.execute ("select id from table where time > ?", time) { row ->
l << row[0]
}
这将打开一个到数据库的连接，创建一个声明和结果集，然后运行l << it[0]每行的DB回报。请注意，代码在sql.execute()内部运行，但它可以访问在sql.execute()（row）中定义的变量的局部变量（l）和。
使用这种代码，您甚至可以随时生成HTTP请求的结果，而无需随时在RAM中保留大部分页面。就我而言，我只用几KB的内存就可以将一个2MB的文档传输到浏览器，然后浏览器会咀嚼83s来解析它。
我发现使用接口解析器比深回调更容易，它通过几个类连接起来。 MS的版本比我的Unity更有趣。这提供了一种更加清洁的访问不应紧密耦合的类的方法