断开连接的记录集
我认识的人想要使用 应用程序中断开连接的记录集。 对我来说，听起来如果我有一个 ORM 工具，就真的不需要接触断开连接的记录集。 我对 ORM 的理解是，ORM 负责避免不必要地长时间占用连接，从而解决了对断开连接的记录集的需求。 是否存在您仍想使用断开连接的记录集的情况？
Someone I know wants to use diconnected recordsets in an application. To me it sounds like if I have a ORM tool there would really be no need to even touch disconnected recordsets. The way I understand it with ORM the ORM takes care of not hugging connections for unnecessarily long amounts of time, solving the need for a disconnected recordset. Is there an instance in which you would still want to use a disconnected recordset?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
制作的 ADO 记录集可以作为数据容器对象的不错选择，作为 VBA 类型（结构）、集合、字典等的替代方案，即强数据类型可为空字段**，具有对过滤、排序、搜索的内置支持、输出到格式化文本/xml/数组、分页、克隆等。根据定义，构造的 ADO 记录集是断开连接的。
也许这并不完全符合您的想法，但它是您问题的有效答案，即即使您有 ORM，您仍然希望使用断开连接的记录集的示例。
** 类似地，ADO 参数对象是 Variant 类型的常见替代方案，因为与 VB 内部类型不同，它们既可以是强数据类型，也可以为空。
A fabricated ADO recordset can be a good choice of container object for data, as an alternative to a VBA Type (struct), Collection, Dictionary, etc i.e. strongly data typed nullable fields** with built-in support for filtering, sorting, searching, output to formatted text/xml/array, paging , cloning, etc. A fabricated ADO recordset is disconnected by definition.
Perhaps this isn't quite what you had in mind but it is a valid answer to your question i.e. an example of when you would still want to use a disconnected recordset, even though you have an ORM.
** Similary, ADO Parameter objects are a usual alternative for the Variant type in that, unlike VB intrinsic types, they can be both strongly data typed and nullable.
我会考虑在小型“组装后忘记”应用程序中或当您有简单的报告需求（例如只读网格视图）时使用记录集。
这包括任何感觉像是您能做的最快的事情的应用程序，并且您看不到它稍后会改变的原因。
但是，如果您要构建一个稍微高级的、可维护的、健壮的应用程序，具有业务逻辑等，请不要使用记录集。
但可以肯定的是，它还是有用的。
I'd consider using a recordset in small "assemble and forget" applications or when you have simple reporting needs like read-only grid views.
That includes any application where it feels like the quickest thing you can do, and you don't see a reason it will change later on.
However, if you are going to build a slightly advanced, maintainable, robust application, with business logic and the like, don't go with recordsets.
But sure, there's still use for it..