|
|
|
 |
 |
Nik Legaloff Blog. Сессия работы с данными. Комментарии. |
 |
|
 |
 |
Для тех, у кого возникает потребность в определении области, легко доступной из любого участка кода, которая живёт на протяжении всего реквеста и является уникальной для каждого клиента.
Пишла в голову идея, реализацией которой я давно пользуюсь. Сча решил ей поделиться.
Для чего нужна такая сессия?
1. В ней удобно хранить свой connectionManager, который будет раздавать соединения именно для этого клиента.
2. Её легко по событию OnUnload(перегрузить его в своём базовом типе страницы) или по Application_EndRequest можно закрывать и не бояться забыть это сделать явно. При закрытии можно высвобождать занятые ресурсы(если их учёт ведёт обьект, лежащий в датаСессии) можно камитить по умолчанию все бизенес транзакции.
3. Там же место экземпляру UnitOfWork и IdentityMap
4. Она может быть легкодоступна (DataSession.Current.)
Реализация проста.
Статическое поле - hashtable в котором лежат сами сессии, а key у элемента hashtable - любой уникальный идентификатор клиента(в самом простом случае идентификатор сессии, но можно реализовать и свой механизм)
2 статических метода.
1. Получить экземпляр текущей сесии(если таковой отсутсвует - создать новый)
2. Закрыть текущую сессию( и удалить её из коллекции)
ну а в самом класе datasesion ложим экземпляры нужных обьектов и делаем к ним проперти. Если используем бизнесТранзакцию то реализуем свои методы, типа Commit(), Rollback()
Кстати удачно получается реализация Rollback, при этом просто сбрасывается UnitOfWork и очищается IdentityMap. Опля, и все действия забыты
пример реализации Сессия работы с данными для web
ЗЫ. Не стоит забывать что вышесказанное эффективно только для webApp. для winApp совсем другая история.
Nik Legaloff
11 August 2005 19:15
|
| 13 August 2005 21:30 |
Max951 |
REСессия в ASP.NET - это пережиток прошлого и пользоваться ею - правило дурного тона.
|
| 15 August 2005 01:36 |
Nik Legaloff |
REПравилом дурного тона считается невнимательно читать посты и писать глупые ответы(в данном контексте).
Прочти ещё раз написаное мной выше и наверно заметешь, что никакой речи о HttpSessionState тут не идёт.
Хотя в одном моменте она всё же упоминается. Там где я предложил использовать её идентификатор(если лень свой механизм реализовывать), при этом идентификатор используется ТОЛЬКО в течении выполнения запроса. Между запросами он не используется и HTTP сессия тоже НЕ используется. Если сесия рухнет между запросами то ничего страшного не произойдёт.
|
| 16 August 2005 12:07 |
Max951 |
REда прошу прощения, не внимательно всё просмотрел
|
| 17 August 2005 01:47 |
Urchik |
uuu2Max951 : а чем плохо использование сессий?
|
| 17 August 2005 17:06 |
Dimon aka Manowar |
2 UrchikНепредсказуемостью наличия Это как кеш, только в кеше хоть ожидаешь, что объекта может не быть, а сессия сдохнет тихонечко (сама по себе или вместе с приложением) и никто и не заметит
|
| 17 August 2005 20:22 |
Max951 |
RE 2 UrchikЕдинтсвенный момент, когда я пользуюсь сессией - это если мне созданный обьект нужно передать модальному окну и обратно, других надобностей у меня в ней нету
|
| 18 August 2005 00:43 |
Nik Legaloff |
Зачем же передавать обьект, когда можно передать его ID. Или если надо то ещё и имя его типа. Передавать лучше презистентные обьекты
|
| 18 August 2005 09:10 |
Max951 |
RE: Зачем же передавать обьект, когда можно передать его ID. Или если надо то ещё и имя его типа. А что мне даст ID Если нужен целиком обьект?
|
| 18 August 2005 09:14 |
Nik Legaloff |
Ну так его можно всегда извлечь из хранилища по ID :)Ну если уже совсем нельзя ложить его в долговременное хранилище(БД, файл) то можно поместить в статическую коллекцию, к примеру hashTable, сгенерировав для него ключ. и по нему можно обект потом получить.
|
| 19 August 2005 17:32 |
Dimon aka Manowar |
Ну на самом деле получается та же сессияИ точно так же, как и сессия статический хеш может упасть
Хотя конечно лучше все параметры тягать в запросах к страницам и не пользоваться вспомогательными хранилищами.
|
| 23 August 2005 20:01 |
Игорь Т. |
RE: Ну на самом деле получается та же сессияНу, это скорее не сессия а кэш получается
следи за руками:
1. У нас есть кэш объектов. Identity Map. ВСЯКИЙ объект перед тем, как загрузить проверяем на наличие в кэше. Если нет - грузим. Все это есессн опрозрачно на уровне DAL сделано.
2. Передаем модальному окну ID экземпляра. Окно себе просто просит DAL дать ему экземпляр такой-то. И тот ему дает. А из кэша ли он, или вновь загружается после смерти процесса - окошку как бы до фалды...
Т.е. если просто ложить экземпляр в сессию и ожидать его там найти в модлаьном окне - это плохо. А что делать, если его там нет? Ну, там сессия умерла вместе с процессом и т.д. А вот в случае такой вот вертикальной структуры, как написано выше, все будет зашибись как устойчиво работать
>> Хотя конечно лучше все параметры тягать в запросах к страницам и не пользоваться вспомогательными хранилищами.
это как сказать... хороший кэш еще никому не вредил 
|
| 23 August 2005 20:06 |
Игорь Т. |
RE Не стоит забывать что вышесказанное эффективно только для webApp. для winApp совсем другая история. Ну почему же... Разве что некоторыми деталями реализации отличаться будет. А в целом - идея как раз шаблонная и универсальная. Подходит и для win и для web.
К слову, в том же Hibernate объект Session именно все вышеописанное на себя и берет (IdentityMap, UnitOfWork etc). Вот разве что доступность к нему не забита жестко (DataSession.Current).
Это дело оставили разработчикам, чтобы те сами решили, каким именн ообразом манагерить эти сессии: можно одну на HttpContext, можно одну на сессию, можно ассоциировать сессии именно с бизне-транзакциями...
|
| 24 August 2005 10:06 |
Max951 |
RE:RE: Ну на самом деле получается та же сессияНа самом деле всё почти также как ты описал
|
|
|
|
|
 |
 |
 |
|
|