Время жизни сеанса в клиент-серверной среде вне ASP.NET - PullRequest
0 голосов
/ 02 августа 2011

Мы в значительной степени полагаемся на механизм впрыска с Ninject. В настоящее время мы боремся, как обрабатывать сессии. Мы много читаем об управлении сессиями и хотим реализовать сессию для каждой бизнес-конверсии. У нас есть простая инфраструктура, подобная следующей:

public class Repository<TEntity> : IRepository<TEntity>
    where TEntity : class, IEntity
{
    public Repository(ISession session)
    {
        this.Session = session;
    }

    protected ISession Session { get; private set; }

    public TEntity FindBy(Guid key)
    {
        return this.Session.Get<TEntity>(key);
    }
    /// rest omitted
}

Потребитель репо выглядит следующим образом:

    public class Consumer {
            public Consumer (Repository<SomeEntity> repo, ISession session)
            public void DoSomeWork() {
                    using (var tx = session.BeginTransaction()) {
                       repo.FindBy(someId);
                       /// etc.
                       tx.Commit();
            }
    }

ISession, введенный в экземпляр Repo, гарантированно совпадает с ISession в потребителе. Мы создаем небольшое серверное приложение, в котором размещены несколько служб инфраструктуры, у которых есть время жизни серверного процесса и некоторые конечные точки WCF. Поскольку мы контролируем фрезерные станки, инфраструктурные службы в основном находятся здесь, чтобы контролировать создание и правильную утилизацию «программных» машин и их конечных автоматов.

Мы думали о следующей структуре управления сессиями:

  • Инфраструктурные услуги: сеанс на услугу
  • Конечные точки WCF: сеанс на OperationContext
  • Другие компоненты:?

В некоторых случаях конечные точки WCF должны подключаться к службам инфраструктуры. Как бы вы справились с сессиями там?

Любой совет?

1 Ответ

0 голосов
/ 02 августа 2011

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

...