Здравствуйте, <Аноним>, Вы писали:

А>Пока только исследуем этот вопрос. А интересует меня следующее, на сколько мне извесно NH для поддержки агригации и lasy load требует использования собственных коллекций,

Не совсем верно. Для агрегации он использует динамически сгенерированные прокси-классы (см. Castle.DynamicProxy), да и то не всегда, а только в том случае, когда агрегируемый класс был помечен как lazy="true". А насчет коллекций -- он требует того, чтобы тип свойства, на которое мапится та самая коллекция, был типа
IList, ISet, и т.д. Но как и везде в NHibernate это свойство совершенно не обязано быть public (а уж при использовании коллекций просто таки обязано не быть). Я делаю следующим образом:

public class Bar
{
    // Какие-то свойства.
}

public class BarCollection : Collection<Bar>
{
    public BarCollection()
    {
    }
    
    // Вот этот конструктор архиважен.
    public BarCollection(IList<Bar> list) :
        base(list)
    {
    }
}

public class Foo
{
    private IList<Bar> bars;
    
    // Мапится именно это свойство.
    protected IList<Bar> InternalBars
    { 
        get { return bars; }
        set { bars = value; }
    }
    
    // А доступ к коллекции осуществляется через это свойство. Можно
    // создание коллекции соптимизировать, но это и так O(1) операция.
    public BarCollection Bars
    {
        get { return new BarCollection(InternalBars); }
    }
}

А>ну и кроме того объект может находится в кэше мапера.

Их, по сути, два -- тот, который ISession (он же Unit of Work) и опциональный кэш второго уровня...

А>Не будут ли тут проблемы, если скажем при открытии формы я запрошу состояние агрегирующего объекта (вместе с подчиненными объектами), что -то там буду менять, а потом нажму cancel и сделаю откат к сохраненному состоянию.

...от сессии объект можно отцепить с помошью Evict. Но тогда перестанет работать ленивая загрузка. Отцепить можно, например, по нажатию Cancel. Но в таком случае нет гарантии, что остальная система будет работать с валидными данными.