It's possible. But it's hard to tell what will work best at this stage.

For the record, I use batch-size as my default approach, but I'm not sure if
that's the best in this case. Only an actual profiling of the app (which
should also consider things like caching) will tell what's best.
But again, we don't even know what the performance requirements of the app
will be, so...

   Diego


On Thu, May 6, 2010 at 18:32, Fabio Maulo <[email protected]> wrote:

> In this case the eagerly load is not efficient.
> The best way to do it with fews round trips is using batch-size at
> collections (the amount of round trips depend on the size of batch-size).
>
> @DaveL
> To do it you don't need to write queries. Only get the parent and use it
> with an opened NH's session... NH will do the hard work.
>
> On Thu, May 6, 2010 at 5:25 PM, Diego Mijelshon <[email protected]>wrote:
>
>> First of all, NHibernate can handle cases like this perfectly, and with
>> very little effort.
>> But... you need to let it work.
>> You seem to come from a DB-oriented background, and you are thinking of
>> the SQL and roundtrips first (client side composition?), which is not the
>> best way to take advantage of NH's features.
>>
>> There are (at least) three steps for a good design:
>> - Define your classes (you already did). For better query possibilities,
>> make all relationships bidirectional.
>> - Create the queries for your use cases using a DAO or Repository
>> *without* thinking about microoptimization yet. You can start by returning
>> the parent and let the children/grandchildren collection lazy load
>> - Optimize.
>>
>> We could be getting a little ahead of ourselves... but the better approach
>> for optimization in this case probably involves 3 roundtrips (parent,
>> children, granchildren). The good news is, NHibernate can handle that
>> perfectly.
>> Here's one way of doing it:
>> http://ayende.com/Blog/archive/2010/01/16/eagerly-loading-entity-associations-efficiently-with-nhibernate.aspx
>>
>>    Diego
>>
>>
>>
>> On Thu, May 6, 2010 at 09:23, DaveL <[email protected]> wrote:
>>
>>> Hi,
>>>
>>> I’m working on the design of a new project and I was considering using
>>> nHibernate as my ORM.  However, I have a specific need and I’m unsure
>>> whether nHibernate can answer the call.
>>>
>>> I would like to do client-side composition.
>>>
>>> Given those premises:
>>> •       I have the classes Parent, Child and GrandChild, with appropriate
>>> collection properties.
>>> •       Each of those classes have a property Name.
>>> •       I have already loaded a Parent called “parent1”.
>>> •       “parent1” has 100 Child already loaded, with names “child1”,
>>> “child2”, …, “child100”.
>>> •       No GrandChild is loaded yet.
>>> •       Suppose each Child owns 10 GrandChild objects, although we don’t
>>> know it yet since GrandChild aren’t loaded yet, for a total of 1000
>>> GrandChild.
>>>
>>> I want to load GrandChild objects, given the Parent’s Name “parent1”.
>>> What I want is to get all 1000 GrandChild from my web service and
>>> compose them client-side with my 100 Child objects based on the
>>> foreign key, because I don’t want to do 100 round-trips to the
>>> backend.
>>>
>>> If I was to write the SQL query for that, I would write something
>>> similar to the following:
>>>
>>> Select gc.Id, gc.ChildId, gc.Name
>>> From Parent p inner join Child c on p.Id = c.ParentId
>>>     Inner join GrandChild gc on c.Id = gc.ChildId
>>> Where p.Name = “parent1”
>>>
>>> Then, I would compose each GrandChild object with its parent, using
>>> the ChildId foreign key.
>>>
>>> How would you resolve that problem with this nHibernate?
>>>
>>> Thanks!
>>> dave.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "nhusers" group.
>>> To post to this group, send email to [email protected].
>>> To unsubscribe from this group, send email to
>>> [email protected]<nhusers%[email protected]>
>>> .
>>> For more options, visit this group at
>>> http://groups.google.com/group/nhusers?hl=en.
>>>
>>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "nhusers" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected]<nhusers%[email protected]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/nhusers?hl=en.
>>
>
>
>
> --
> Fabio Maulo
>
>  --
> You received this message because you are subscribed to the Google Groups
> "nhusers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<nhusers%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/nhusers?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en.

Reply via email to