处理 Web 服务 XML 模式中的轻量级（骨架）表示的最佳方式？
我是整个网络服务领域的新手，所以如果这个问题看起来愚蠢或明显，请原谅！
我有许多实体可以由我正在创建的新 Web 服务提供。其中一些实体由非常大的对象图组成。
然而，有时客户端会想要搜索其中一些实体并返回一个（可能很大的）结果集。我认为这个结果集应该包含这些巨大实体的轻量级表示，而不是整个实体。毕竟它们只会显示在 GUI 上的“找到的实体”列表中……然后单独检索。
处理这个问题的好模式是什么？我特别关心它与我的 XML 模式有何关系？如果我使用相同的 XML 元素类型作为重量级表示（例如使用 isSkeleton 布尔开关），那么我的所有 XML 约束都会变得无用（因为子元素不会存在）。
另一方面，如果我为每个潜在的大型实体（具有其自己的 XML 定义）创建专门的“轻量级”DTO，那么我需要在这些 DTO 和我的实体之间进行转换。
I'm new to the whole web service space, so pardon the question if it seems stupid or obvious!
I have a number of entities that can be provided by a new web service that I am creating. Some of these entities are composed of very large graphs of objects.
However, at times the client will want to search for some of these entities and get back a (potentially large) result set. I am thinking that this result set should contain a lighter weight representation of these huge entities, rather than the entire entity. After all they are only going to be displayed in a 'entities found' list on a GUI...and then individually retrieved.
What's a good pattern for handling this problem? I am particularly concerned in how it relates to my XML schema? If I use the same XML element type as the heavy weight representation (say with an isSkeleton boolean switch), then all of my XML constraints are rendered useless (because child elements won't be there).
On the other hand, if I make a specialized "lightweight" DTO for every potentially large entity (with its own XML definition) then I need to hassle with the conversion to and from these DTOs and my entities.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不确定我是否遵循您所描述的内容，但听起来您需要执行以下操作：
这听起来像是 Solr 的理想用途。 Solr 是构建在 Lucene 之上的开源搜索框架。它使用 XML 作为负载基础，通过 HTTP 提供对基于 Lucene 的搜索索引的访问。它是面向 REST 的，也支持 JSON，因此与语言无关。
Solr 的大多数实现都在幕后运行，可以访问网站搜索结果页面后面提供的结果。您的要求实际上可能非常适合直接公开对 Solr 服务器查询的访问。处理结果的所有元素都已处理完毕——分页、过滤、排序等。所有您确实不想自己做的后勤工作。
作为实施者，您真正的工作是确定搜索索引中包含哪些内容。索引的结构可以保存变体实体的共同元素，并且搜索速度将非常快。在检索给定结果集时，您的应用程序可以从其原始源检索实体的更深入的详细信息（如果您不想将整个实体推送到搜索索引中，这是另一种可能性。）
Not sure if I'm following what you're describing, but it sounds like you need to do the following:
This sounds like an ideal use for Solr. Solr is the open-source search framework built on top of Lucene. It provides access over HTTP to a Lucene-based search index, using XML as the payload basis. It is REST-oriented, speaks JSON as well, so it's language-agnostic.
Most implementations of Solr run behind-the-scenes, with access to results served up behind a website's search results page. Your requirements might actually be a great fit for exposing access to a Solr server's query directly. All the elements of working with the results are already handled -- paging, filtering, sorting, etc. All the logistics work that you really don't want to do yourself.
As the implementor, your real work is determining what goes in your search index. The index could be structured to hold the common elements of your variant entities, and the search speed would be blazingly fast. Upon retrieval of a given resultset, your application could retrieve deeper details of an entity from its original source (if you didn't want to push the entire entity into the search index, which is another possibility.)