контроль параллелизма версии для длительной сессии. NHibernate. ASP.NET MVC

Question

1) Что является более подходящим/обычно используемым подходом для контроля параллелизма? Пессимистическая или оптимистическая блокировка?

2) Как уведомить пользователя, есть ли блокировка для элемента или произошел откат?

3) Предположим, я добавил всю необходимую разметку (например, optimistic-locking="false", чтобы исключить свойства я не хочу быть вовлеченным в сравнении) на мой объект отображения файлов и определили Version свойство на сущностей классов для обработки контроль параллелизма. Этого будет достаточно, и весь материал будет обработан в/NHibernate. Должны ли присутствовать дополнительные модификации? Например, в Repository?

public class Repository<T> : IRepository<T> where T : AbstractEntity<T>, IAggregateRoot 
{ 
    private ISession session; 

    public Repository(ISession session) 
    { 
     this.session = session; 
    } 

    public T Get(Guid id) 
    {    
     return this.session.Get<T>(id);    
    } 
    public IQueryable<T> Get(Expression<Func<T, Boolean>> predicate) 
    { 
     return this.session.Query<T>().Where(predicate);    
    } 
    public IQueryable<T> Get() 
    { 
     return this.session.Query<T>();    
    } 
    public T Load(Guid id) 
    { 
     return this.session.Load<T>(id); 
    } 
    public void Add(T entity) 
    {    
     using(var transaction = this.session.BeginTransaction()) 
     { 
      this.session.Save(entity); 
      transaction.Commit(); 
     } 
    } 
    public void Remove(T entity) 
    {    
     using(var transaction = this.session.BeginTransaction()) 
     { 
      this.session.Delete(entity); 
      transaction.Commit(); 
     } 
    } 
    public void Remove(Guid id) 
    {    
     using(var transaction = this.session.BeginTransaction()) 
     { 
      this.session.Delete(this.session.Load<T>(id)); 
      transaction.Commit(); 
     } 
    } 
    public void Update(T entity) 
    {    
     using(var transaction = this.session.BeginTransaction()) 
     { 
      this.session.Update(entity); 
      transaction.Commit(); 
     } 
    } 
    public void Update(Guid id) 
    {    
     using(var transaction = this.session.BeginTransaction()) 
     { 
      this.session.Update(this.session.Load<T>(id)); 
      transaction.Commit(); 
     } 
    } 
} 

// DI 
public class DataAccessModule : Ninject.Modules.NinjectModule 
{ 
    public override void Load() 
    { 
     this.Bind<ISessionFactory>() 
      .ToMethod(c => new Configuration().Configure().BuildSessionFactory()) 
      .InSingletonScope(); 

     this.Bind<ISession>() 
      .ToMethod(ctx => ctx.Kernel.TryGet<ISessionFactory>().OpenSession()) 
      .InRequestScope(); 

     this.Bind(typeof(IRepository<>)).To(typeof(Repository<>)); 
    } 
} 

Я использую длинную сессию с несколькими транзакциями.

Спасибо!

Answer 1

Ваш репозиторий никогда не должен обрабатывать области транзакций. Это совершенно другое требование, и Repository can not знает, какие границы должны иметь транзакции.

Сделки с инфраструктурой следует обрабатывать где-то снаружи. Если вы используете ASP.NET MVC - подходят фильтры действий (см. Реализацию проекта Sharp Architecture).

Если его ASP.NET-модуль или глобальная обработка asax могут быть применены.

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

Answer 2

Вам не хватает рисунка «unit of work».