在.NET 4.0中,可以DirectorySearch的方式,让我翻阅他们返回LDAP结果? [英] In .Net 4.0, can DirectorySearch return LDAP results in a way that allows me to page through them?

查看:89
本文介绍了在.NET 4.0中,可以DirectorySearch的方式,让我翻阅他们返回LDAP结果?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我的工作在C#中,我试图用DirectorySearch来查询一个非常大的Microsoft ActiveDirectory的LDAP服务器的组。

I am working in C#, and am trying to use DirectorySearch to query the groups of an extremely large Microsoft ActiveDirectory LDAP server.

所以,在我的应用程序,我将有组的分页列表,搜索功能。当然,我不希望我的锤LDAP服务器,每次我点击下一页通过我的整个结果集这些查询。

So, in my application, I'm going to have a paged list of groups, with searching capability. Naturally, I don't want to hammer my LDAP server with passing me the entire result set for these queries every time I hit "Next Page".

有没有一种方法,使用DirectorySearch,只提取任意单个页面的结果,而不是返回整个结果集的一个方法调用?

Is there a way, using DirectorySearch, to retrieve ONLY a single arbitrary page's results, rather than returning the entire result-set in one method call?

同样的问题:

  • <一个href="http://stackoverflow.com/questions/4693284/directorysearch-pagesize-2-doesnt-work">DirectorySearch.PageSize = 2不工作
  • <一个href="http://stackoverflow.com/questions/3488394/c-active-directory-services-findall-returns-only-1000-entries">c# Active Directory服务的findAll()只返回1000个条目
  • DirectorySearch.PageSize = 2 doesn't work
  • c# Active Directory Services findAll() returns only 1000 entries

很多问题,像这样的存在,如果有人问起分页(来自LDAP服务器的意思是应用服务器),并得到涉及每页和响应的siz​​eLimit。然而,这些特性仅仅影响C#服务器和LDAP服务器之间寻呼,并且在最后,该DirectorySearch具有唯一相关的方法是FindOne()和的FindAll()。

Many questions like these exist, where someone asks about paging (meaning from LDAP server to app server), and gets responses involving PageSize and SizeLimit. However, those properties only affect paging between the C# server and the LDAP server, and in the end, the only relevant methods that DirectorySearch has are FindOne() and FindAll().

我正在寻找的基本上是FindPaged(pageSize的,页面编号)(该页面编号是真正重要的一点,我不只是想前1000个结果,我希望(例如)100'th集1000的结果。该应用程序不能等到10万条记录必须从LDAP服务器到应用服务器通过,即使它们被分解成1000个记录块。

What I'm looking for is basically "FindPaged(pageSize, pageNumber)" (the pageNumber being the really important bit. I don't just want the first 1000 results, I want (for example) the 100'th set of 1000 results. The app can't wait for 100,000 records to be passed from the LDAP server to the app server, even if they are broken up into 1,000-record chunks.

据我所知,DirectoryServices.Protocols有SearchRequest,这(我想?),可以使用PageResultRequestControl,它看起来像它有我要找的(虽然它看起来像寻呼信息进来饼干我不知道我怎么会被认为检索)。但是,如果有一种方法可以做到这一点无需重写整个事情要使用的协议,而不是,我宁愿没有这样做。

I understand that DirectoryServices.Protocols has SearchRequest, which (I think?) allows you to use a "PageResultRequestControl", which looks like it has what I'm looking for (although it looks like the paging information comes in "cookies", which I'm not sure how I'd be supposed to retrieve). But if there's a way to do this without rewriting the entire thing to use Protocols instead, I'd rather not have to do so.

我不能想象有没有办法做到这一点。即使SQL有ROW_NUMBER。

I just can't imagine there's no way to do this... Even SQL has Row_Number.

更新: 该PageResultRequestControl于事无补 - 这是只进和顺序(你必须调用,并得到前N个结果,然后才能获得所必需的曲奇令牌拨打电话获得导致N + 1)

UPDATE: The PageResultRequestControl does not help - It's forward-only and sequential (You must call and get the first N results before you can get the "cookie" token necessary to make a call to get result N+1).

不过,Cookie并不似乎有某种可重复顺序的......在一个结果集,我的工作,我迭代逐一通过的结果,每一次的cookie出来正是如此:

However, the cookie does appear to have some sort of reproducible ordering... On a result set I was working on, I iterated one by one through the results, and each time the cookie came out thusly:

1: {8, 0, 0, 0}
2: {11, 0, 0, 0}
3: {12, 0, 0, 0}
4: {16, 0, 0, 0}

当我通过两个两个迭代,我得到了相同的号码(11,16)。 这使我想到,如果我能想出​​如何生成这些数字的code,我可以创建一个cookie特设的,这会给我正是我要寻找的页面。

When I iterated through two by two, I got the same numbers (11, 16). This makes me think that if I could figure out the code of how those numbers are generated, I could create a cookie ad-hoc, which would give me exactly the paging I'm looking for.

推荐答案

可悲的是,它似乎有可能不是一个办法做到这一点鉴于目前的C#库。

Sadly, it appears there may not be a way to do this given current C# libraries.

所有标准的C#4.0 LDAP库返回前N个结果(如,的FindAll(),它返回每个结果,FindOne(),它返回的第一个结果,或信息搜索结果与PageResultRequestControl,返回结果N至N + M,但需要你到N-1的检索结果1之前,你有,你可以请求传递,以获得下设置一个cookie标记。

All of the standard C#4.0 LDAP libraries return Top-N results (As in, FindAll(), which returns every result, FindOne(), which returns the first result, or SearchResult with PageResultRequestControl, which returns results N through N+M but requires you to retrieve results 1 through N-1 before you'll have a cookie token that you can pass with the request in order to get the next set.

我一直没能找到任何第三方LDAP库,允许这一点,无论是。

I haven't been able to find any third-party LDAP libraries that allow this, either.

除非一个更好的解决方案被发现,我的前进道路将修改界面,而不是显示顶的X结果,没有客户端的分页功能(显然仍在使用适当的服务器端分页)。​​

Unless a better solution is found, my path forward will be to modify the interface to instead display the top X results, with no client paging capabilities (obviously still using server-side paging as appropriate).

我会在以后的日子奉行一个只进寻呼系统,通过将更新后的cookie到客户端的响应,并配有更多结果式按钮的点击它传递回来。 这可能是值得追求的,在以后的日子,这些cookie能否被手工制作的。

I may pursue a forward-only paging system at a later date, by passing the updated cookie to the client with the response, and passing it back with a click of a "More Results" type of button. It might be worth pursuing at a later date, whether or not these cookies can be hand-crafted.

更新: 我采访了微软的支持,并证实了这一点 - 有没有办法做到动态页面与LDAP服务器。这是LDAP服务器本身的限制。

UPDATE: I spoke with Microsoft Support and confirmed this - There is no way to do dynamic paging with LDAP servers. This is a limitation of LDAP servers themselves.

您可以使用协议和寻呼控制(如果您的LDAP服务器支持它)挺身而出的意愿,但没有跨服务器(甚至是跨版)标准的饼干,所以你不能合理工艺你自己的,而且也不能保证cookie可以重复使用重复的查询。

You can use Protocols and the Paging control (if your LDAP server supports it) to step forward at will, but there is no cross-server (or even cross-version) standard for the cookie, so you can't reasonably craft your own, and there's no guarantee that the cookie can be reused for repeated queries.

一个完整的解决方案包括使用协议(与寻呼如上)拉你分页的结果集为SQL,无论是到一个临时表或永久存储表,并让你的用户页面和排序,通过该结果在传统的设置方式。记住你的结果会不会是precisely最新的,但也有一些聪明的缓存更新就可以最大限度地减少风险。

A full solution involves using Protocols (with Paging as above) to pull your pageable result set into SQL, whether into a temp table or a permanent storage table, and allow your user to page and sort through THAT result set in the traditional manner. Bear in mind your results won't be precisely up to date, but with some smart cache updating you can minimize that risk.

这篇关于在.NET 4.0中,可以DirectorySearch的方式,让我翻阅他们返回LDAP结果?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆