NHibernate/Castle.ActiveRecord; Управление сеансом; WinForms

Question

мой первый реальный (не тест) NHibernate/Castle.ActiveRecord проект развивается быстро. Я работаю с NHibernate/Castle.ActiveRecord около месяца, но до сих пор не знаю, как обрабатывать сеансы в приложении WindowsForms.

Общие погрузо-методы шва не работать для меня:

• SessionPerRequest, SessionPerConversation и т.д. все работают только для WebApplications и т.д.
• SessionPerApplication не Рекомендуемые нами очень опасно/когда я правильно
• SessionPerThread не очень полезен, так как у меня либо есть только один поток, либо WindowsForms-thread, либо для каждой кнопки - новый поток. Первое, что заставит мое приложение использовать слишком много памяти и хранить старые объекты в memmory. С помощью рабочих потоков для нажатия кнопки ech я отключил бы ленивую загрузку, так как мои загруженные объекты будут жить дольше, чем поток.
• SessionPerPresenter также не работает, поскольку распространено, что я открываю «суб-презентатор» в форме, позволяющей пользователю искать/загружать/выбирать некоторые объекты, на которые ссылаются (foreigen key), и привести к уничтожению презентатора - что означает сеанс закрыт - но объект, используемый в «супер-презентаторе» для заполнения ссылочного свойства (foreigen key).

Я использовал Google и бинг часами и много читал, но нашел только один хороший сайт о моем случае: http://msdn.microsoft.com/en-us/magazine/ee819139.aspx. Там SessionPerPresenter используется, но для «суб-презентатора» ему предоставляется только id, а не весь объект! И это говорит о том, что в этом примере нет никаких ключей ключа и нет сценариев, в которых объект возвращается в «супер-презентатор».

Qestions

1. есть ли другой способ обработки для WindowsForms/десктоп-приложение сессии?
2. Я мог бы добавить свойство session-session или параметр-session-constructor для всех моих презентаторов, но мне нехорошо иметь сеансовую обработку всего моего ui-кода.
3. Когда происходит исключение, NHibernate хочет, чтобы я убил сессию. Но если это «только» исключение бизнес-логики, а не исключение NHibernate?

Пример

Я пытаюсь сделать пример крышку большой частью моей проблемы.

// The persisten classes 
public class Box 
{ 
    public virtual int BoxId{get;set;} 
    public virtual Product Content{get;set;} 
    ... 
} 

public class User 
{ 
    public virtual int UserId{get;set;} 
    public virtual IList<Product> AssigenedProducts{get;set;} 
    ... 
} 

public clas Product 
{ 
    public virtual int ProductId{get;set;} 
    public virtual string PrductCode{get;set;} 
} 

.

// The presenter-classes 
public class ProductSearchPresenter : SearchPresenter<Product> { ... } 
public class ProductEditPresenter : EditPresenter<Product> { ... } 
public class UserSearchPresenter : SearchPresenter<User> { ... } 
public class UserEditPresenter : EditPresenter<User> { ... } 
public class BoxSearchPresenter : SearchPresenter<Box> { ... } 
public class BoxEditPresenter : EditPresenter<Box> { ... } 
// The search-presenters allow the user to perform as search with criterias on the class defined as generic argument and to select one of the results 
// The edit-presenters allow to edit a new or loaded (and given as parameter) object of the class defined as generic argument 

Теперь у меня есть следующие примеры использования, которым все могут быть выполнены в одном приложении, в то же время асинхронный (использование просто вызывают переключение между докладчиками).

1. используя экземпляр BoxSearchPresenter для поиска и выберите объект
   1. часть этого USECASE является использование экземпляра ProductSearchPresenter заполнить критерии в BoxSearchPresenter
   2. часть этого USECASE является использование экземпляр BoxEditPresenter для редактирования и сохранения выбранного объекта в BoxSearchPresenter инстанции
2. используя экземпляр UserSearchPresenter для поиска и выбора объекта
   1. часть этого USECASE является использование экземпляра UserEditPresenter для редактирования и сохранения slected объекта UserSearchPresenter
   2. частью этого USECASE является использование ProductSearchPresenter для поиска и выбора объектов, которые будут добавлены в User.AssignedProducts ,
3. Использование экземпляра ProductSearchPresenter для поиска и выбора объекта.
   1. часть этой утилиты - это использование экземпляра ProductEditPresenter для редактирования и сохранения выбранного объекта ProductSearchPresenter.

Это только небольшая коллекция usecases, но есть Allready много проблем, у меня есть.

• UseCase 1. и 2. запускаются одновременно в одной и той же нитью.
• UseCase 1.1. и 2.2. верните туда выбранные объекты другим ведущим, которые используют эти объекты дольше, чем существуют те, кто загрузил объект.
• UseCase 3.1. может изменить объект, загруженный из 2.2./1.1. до 3.1. был начат, но когда 2.2./1.1. совершается до 3.1. закончен, объект будет сохранен, и невозможно «откат» 3.1.

Answer 1

Вот лишь краткое представление о том, что я нашел лучше всего вписываться в нашу архитектуру приложений WinForms (на основе MVP).

Каждый ведущий является конструктором, зависящим от репозиториев, которые ему нужны, например, если у вас есть InvoicePresenter, то у вас есть InvoiceRepository в качестве зависимости, но вы, вероятно, будете иметь CustomerRepository и многие другие в зависимости от сложности (CustomerRepsitory для загрузки всех клиентов в группу со списком клиентов если вы хотите изменить клиента счета-фактуры, что-то вроде этого).

Затем у каждого хранилища есть аргумент constuctor для UnitOfWork. Либо вы можете абстрагировать сессию с помощью шаблона UnitOfWork, либо вы можете зависеть от ваших реплик.

Все подключено вместе контейнером IoC, где мы создаем презентаторов на основе «контекста». Это очень простая концепция, контекст для каждого презентатора и всех суб-презентаторов, которые, в свою очередь, мы создаем как составной блок более сложных презентаторов для уменьшения complexitiy (если, например, у вас есть несколько вкладок опций для редактирования какой-либо сущности или чего-то еще).

Таким образом, на практике этот контекст основан на 90% основе времени, потому что одна форма - это хотя бы один презентатор/представление.

Так, чтобы ответить на ваши вопросы:

1. сессия на ведущий и сессии в разговоре (работает с WinForms, а) только реально используемые модели здесь (и закрытия открытия сессии повсюду, но на самом деле не хороший способ справиться с этим) -

2. Это лучше всего решить путем создания хранилищ, зависит от сеанса, а не от ведущих. Вы делаете докладчиков зависеть от репозиториев, хранилища зависят от сеанса, а когда вы создаете все, вы даете им общий сеанс; но, как я уже заявляю, это практично только в контексте. Вы не можете использовать сеанс для составления счетов-фактур ведущего и других редакторов-редакторов; но вы можете обмениваться сеансом при редактировании счета-фактуры через главную презентацию, а также информацию о счете-фактуре и суб-презентацию счета-фактуры.

3. Просьба уточнить, не понял этого ...