如何在将子集合实体加入关联时急切地获取子集合
假设以下虚构布局，
Dealership
has many Cars
has a Manufacturer
我想编写一个查询，表示为我提供名称为 X 的经销商并获取汽车系列，但在执行此操作时使用针对制造商的联接。我认为这需要使用 ICriteria。我在想这样的事情..
var dealershipQuery = Session.CreateCriteria< Dealership>("d")
.Add(Restrictions.InsenstiveLike("d.Name", "Foo"))
.CreateAlias("d.Cars", "c")
.SetFetchMode("d.Cars", FetchMode.Select)
.SetFetchMode("c.Manufacturer", FetchMode.Join)
.UniqueResult< Dealership>();
但生成的查询看起来与我预期的完全不同。我开始认为某个地方可能需要 DetachedCriteria，但我不确定。
想法？
Assuming the following fictional layout
Dealership
has many Cars
has a Manufacturer
I want to write a query that says get me a Dealership with a Name of X and also get the Cars collection but use a join against the manufacturer when you do so. I think this would require usage of ICriteria. I'm thinking something like this..
var dealershipQuery = Session.CreateCriteria< Dealership>("d")
.Add(Restrictions.InsenstiveLike("d.Name", "Foo"))
.CreateAlias("d.Cars", "c")
.SetFetchMode("d.Cars", FetchMode.Select)
.SetFetchMode("c.Manufacturer", FetchMode.Join)
.UniqueResult< Dealership>();
But the resulting query looks nothing like I would have expected. I'm starting to think a DetachedCriteria may be required somewhere but I'm not sure.
Thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在同一查询中获取集合几乎从来都不是最好的解决方案。
此链接详细介绍了最佳方法之一：http://ayende.com/Blog/archive/2010/01/16/eagerly-loading-entity-associations-efficiently-with-nhibernate.aspx
就我个人而言，我首选的解决方案是要在集合和实体中使用
batch-size，请设置为我的默认页面长度的大小。这样，上面的查询将使用 3 个廉价的、可单独缓存的查询来完成，而不是使用一个昂贵的查询。Fetching collections in the same query is almost never the best solution.
One of the best approaches is detailed in this link: http://ayende.com/Blog/archive/2010/01/16/eagerly-loading-entity-associations-efficiently-with-nhibernate.aspx
Personally, my preferred solution is to use
batch-sizein both the collections and the entities, set to the size of my default page length. That way, your query above would be done with 3 cheap, individually cacheable queries, instead of an expensive one.