Hi,

I have searched all over the forums and all over the web, both for NHibernate and Hibernate answers, but can't seem to answer this. I hope it's simple.

In our model, we have a concept of Entities and Activities. A single entity will have multiple activities. Every day new activities are added to an entity. The problem is that as time goes on, this list grows rather large to the point where in order to load a single Entity and add a new Activity, a list of 1000s of Activities has to be loaded first. Even with Lazy Loading turned on, the first reference to the collection to add a new Activity triggers the load which can cause delays.

What we are looking for is design guidelines when it comes to implementing objects that can potentially have large collections of children.

Thank you very much.

The inverse tag on the collection mapping determines which object manages the assocation. So you should be able to create a new Activity, set its Entity (Parent) property, and Save that activity without ever referencing the Entity's collection. Just manage that like any non-parent/child many-to-one mapping.

OK along the same lines, assume that I want my Entity class to have a finder method e.g. "GetActivitiesByDate". This method would return all of the activities for the entity in a given date range. In order to avoid an anemic domain model, I'd like to have that method on the Entity class, this would imply that the Entity class has to reference NHibernate to load these activities. Would it be better to push the method to a Repository class, this seems to me like Entity will become a big data holder.

One last point, I'd like to Entity class to have an "AddActivity" method. Does this method just set the Activity's "Entity" property and leave the actual saving to the service layer, or would it be better to have the Entity do the reference and also the SaveOrUpdate on a new session?

Thanks for all your help.