Подскажите какой у кого есть опыт в организации кэш-хранилищ в корпоративных веб-приложениях.
Использоваться пока будет для веб-приложения. Зависимости не нужны.
В хранилище могут храниться дерево объектов.

Спасибо!

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

А>Подскажите какой у кого есть опыт в организации кэш-хранилищ в корпоративных веб-приложениях.
А>Использоваться пока будет для веб-приложения. Зависимости не нужны.
А>В хранилище могут храниться дерево объектов.

1)Какая платформа?
2)Inproc\outproc кеш
3)Persisted\transient кеш?
4)Какие объемы?
5)Зачем он нужен?

А>Спасибо!
Да незачто

Здравствуйте, gandjustas, Вы писали:

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

А>>Подскажите какой у кого есть опыт в организации кэш-хранилищ в корпоративных веб-приложениях.
А>>Использоваться пока будет для веб-приложения. Зависимости не нужны.
А>>В хранилище могут храниться дерево объектов.

G>1)Какая платформа?
asp.net 4

G>2)Inproc\outproc кеш
inproc

G>3)Persisted\transient кеш?
а в чем разница?

G>4)Какие объемы?
Пока небольшие. Пока там хранятся DTO которые были созданы на основе Entity сущностей

G>5)Зачем он нужен?
Чтобы хранить добавленные или измененные подобъекты сущности до сохранения в базу

Заодно подскажите, как лучше организовать хранение дерево объектов? DTO имеют простые типы внутри себя

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

А>Здравствуйте, gandjustas, Вы писали:

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

А>>>Подскажите какой у кого есть опыт в организации кэш-хранилищ в корпоративных веб-приложениях.
А>>>Использоваться пока будет для веб-приложения. Зависимости не нужны.
А>>>В хранилище могут храниться дерево объектов.

G>>1)Какая платформа?
А>asp.net 4

G>>2)Inproc\outproc кеш
А>inproc

G>>3)Persisted\transient кеш?
А>а в чем разница?

G>>4)Какие объемы?
А>Пока небольшие. Пока там хранятся DTO которые были созданы на основе Entity сущностей

G>>5)Зачем он нужен?
А>Чтобы хранить добавленные или измененные подобъекты сущности до сохранения в базу

А>Заодно подскажите, как лучше организовать хранение дерево объектов? DTO имеют простые типы внутри себя

А почему бы не воспользоваться EF? У него встроенный UoW, но вызова SaveChanges изменения в базу не попадают.

Здравствуйте, gandjustas, Вы писали:

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

А>>Здравствуйте, gandjustas, Вы писали:

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

А>>>>Подскажите какой у кого есть опыт в организации кэш-хранилищ в корпоративных веб-приложениях.
А>>>>Использоваться пока будет для веб-приложения. Зависимости не нужны.
А>>>>В хранилище могут храниться дерево объектов.

G>>>1)Какая платформа?
А>>asp.net 4

G>>>2)Inproc\outproc кеш
А>>inproc

G>>>3)Persisted\transient кеш?
А>>а в чем разница?

G>>>4)Какие объемы?
А>>Пока небольшие. Пока там хранятся DTO которые были созданы на основе Entity сущностей

G>>>5)Зачем он нужен?
А>>Чтобы хранить добавленные или измененные подобъекты сущности до сохранения в базу

А>>Заодно подскажите, как лучше организовать хранение дерево объектов? DTO имеют простые типы внутри себя

G>А почему бы не воспользоваться EF? У него встроенный UoW, но вызова SaveChanges изменения в базу не попадают.

Решили организовать такую вещь на уровне презентера.

Да и сможет энтити такую ситуацию?
Допустим добавил я новой подобъект Б в объект А на первой вкладке. Но не нажал Сохранить. Получается висит этот подобъект Б со статусом Несохранен в EF.
В итоге я не нажал Сохранить и перешел на вторую вкладку объекта А, где я уже нажал Сохранить.
я храню объект А между раундтрипами в кеше, а уже потом цепляю его к контексту. Получается при нажатии на кнопку Сохранить на второй вкладке у меня сохранятся все объекты со статусом Несохранен

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

А>Здравствуйте, gandjustas, Вы писали:

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

А>>>Здравствуйте, gandjustas, Вы писали:

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

А>>>>>Подскажите какой у кого есть опыт в организации кэш-хранилищ в корпоративных веб-приложениях.
А>>>>>Использоваться пока будет для веб-приложения. Зависимости не нужны.
А>>>>>В хранилище могут храниться дерево объектов.

G>>>>1)Какая платформа?
А>>>asp.net 4

G>>>>2)Inproc\outproc кеш
А>>>inproc

G>>>>3)Persisted\transient кеш?
А>>>а в чем разница?

G>>>>4)Какие объемы?
А>>>Пока небольшие. Пока там хранятся DTO которые были созданы на основе Entity сущностей

G>>>>5)Зачем он нужен?
А>>>Чтобы хранить добавленные или измененные подобъекты сущности до сохранения в базу

А>>>Заодно подскажите, как лучше организовать хранение дерево объектов? DTO имеют простые типы внутри себя

G>>А почему бы не воспользоваться EF? У него встроенный UoW, но вызова SaveChanges изменения в базу не попадают.

А>Решили организовать такую вещь на уровне презентера.

А>Да и сможет энтити такую ситуацию?
А>Допустим добавил я новой подобъект Б в объект А на первой вкладке. Но не нажал Сохранить. Получается висит этот подобъект Б со статусом Несохранен в EF.
А>В итоге я не нажал Сохранить и перешел на вторую вкладку объекта А, где я уже нажал Сохранить.
А>я храню объект А между раундтрипами в кеше, а уже потом цепляю его к контексту. Получается при нажатии на кнопку Сохранить на второй вкладке у меня сохранятся все объекты со статусом Несохранен

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

Здравствуйте, gandjustas, Вы писали:

G>>>А почему бы не воспользоваться EF? У него встроенный UoW, но вызова SaveChanges изменения в базу не попадают.

А>>Решили организовать такую вещь на уровне презентера.

А>>Да и сможет энтити такую ситуацию?
А>>Допустим добавил я новой подобъект Б в объект А на первой вкладке. Но не нажал Сохранить. Получается висит этот подобъект Б со статусом Несохранен в EF.
А>>В итоге я не нажал Сохранить и перешел на вторую вкладку объекта А, где я уже нажал Сохранить.
А>>я храню объект А между раундтрипами в кеше, а уже потом цепляю его к контексту. Получается при нажатии на кнопку Сохранить на второй вкладке у меня сохранятся все объекты со статусом Несохранен

G>Не надо такого делать. Между раундтрипами можешь пройти бесконечно много времени, а столько хранить ты не сможешь.
G>Поведение приложения не должно зависеть от кеша и других, не наблюдаемых пользователем, факторов.

а оно и не зависит. там всё просто: Если не найшли в кеше идем в базу за объектом.
ну так в моем случае, который не высосан из пальца, получается, что в базу ляжет то, что не должно.
Вот и хочу грамотно организовать кеш-хранилище, которое умело бы хранить в себе дерево уже DTO объектов.
Есть идеи по этому поводу?

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

А>Здравствуйте, gandjustas, Вы писали:

G>>>>А почему бы не воспользоваться EF? У него встроенный UoW, но вызова SaveChanges изменения в базу не попадают.

А>>>Решили организовать такую вещь на уровне презентера.

А>>>Да и сможет энтити такую ситуацию?
А>>>Допустим добавил я новой подобъект Б в объект А на первой вкладке. Но не нажал Сохранить. Получается висит этот подобъект Б со статусом Несохранен в EF.
А>>>В итоге я не нажал Сохранить и перешел на вторую вкладку объекта А, где я уже нажал Сохранить.
А>>>я храню объект А между раундтрипами в кеше, а уже потом цепляю его к контексту. Получается при нажатии на кнопку Сохранить на второй вкладке у меня сохранятся все объекты со статусом Несохранен

G>>Не надо такого делать. Между раундтрипами можешь пройти бесконечно много времени, а столько хранить ты не сможешь.
G>>Поведение приложения не должно зависеть от кеша и других, не наблюдаемых пользователем, факторов.

А>а оно и не зависит. там всё просто: Если не найшли в кеше идем в базу за объектом.
Ты же в кеше собираешься изменения хранить.

А>ну так в моем случае, который не высосан из пальца, получается, что в базу ляжет то, что не должно.
Обычно используется один контекст на один запрос. Между запросами контексты не живут потому что см выше.

А>Вот и хочу грамотно организовать кеш-хранилище, которое умело бы хранить в себе дерево уже DTO объектов.
А>Есть идеи по этому поводу?
Ты так и не объяснил зачем. Твои задачи решаются EF.

Здравствуйте, gandjustas, Вы писали:


А>>ну так в моем случае, который не высосан из пальца, получается, что в базу ляжет то, что не должно.
G>Обычно используется один контекст на один запрос. Между запросами контексты не живут потому что см выше.

а как тогда хранить добавленные, но не сохраненные данные между раундтрипами?

еще раз пример:
Допустим добавил я новой подобъект Б в объект А на первой вкладке. Но не нажал Сохранить. Получается висит этот подобъект Б со статусом Несохранен в EF.
В итоге я не нажал Сохранить и перешел на вторую вкладку объекта А, где я уже нажал Сохранить.
Получается при нажатии на кнопку Сохранить на второй вкладке у меня сохранятся все объекты со статусом Несохранен

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

А>Здравствуйте, gandjustas, Вы писали:


А>>>ну так в моем случае, который не высосан из пальца, получается, что в базу ляжет то, что не должно.
G>>Обычно используется один контекст на один запрос. Между запросами контексты не живут потому что см выше.

А>а как тогда хранить добавленные, но не сохраненные данные между раундтрипами?

Добавленные куда и не сохраненные где? Приведи юзкейс где ты считаешь нужен какой-то кеш?
Ест подозрение что ты что-то неправильно делаешь ибо кеши крайне плохо работают при изменении. В основном кеши используются для приближения данных к потребителю. Чтобы пользователь не отправлял запрос на сайт, чтобы веб-приложение не ходило в базу, чтобы база не читала данные с диска.

А>еще раз пример:
А>Допустим добавил я новой подобъект Б в объект А на первой вкладке. Но не нажал Сохранить. Получается висит этот подобъект Б со статусом Несохранен в EF.
Нет, один запрос — один контекст. Контекст хранить между запросами не стоит по той причине что между запросами будет очень много времени проходить и ты заранее не сможешь узнать сколько. Это приведет к тому что при большом количестве пользоватлей у тебя будет в памяти болтаться куча контекстов.

А>В итоге я не нажал Сохранить и перешел на вторую вкладку объекта А, где я уже нажал Сохранить.
А>Получается при нажатии на кнопку Сохранить на второй вкладке у меня сохранятся все объекты со статусом Несохранен
Не получается, см выше.

Здравствуйте, gandjustas, Вы писали:

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

А>>Здравствуйте, gandjustas, Вы писали:


А>>>>ну так в моем случае, который не высосан из пальца, получается, что в базу ляжет то, что не должно.
G>>>Обычно используется один контекст на один запрос. Между запросами контексты не живут потому что см выше.

А>>а как тогда хранить добавленные, но не сохраненные данные между раундтрипами?

G>Добавленные куда и не сохраненные где? Приведи юзкейс где ты считаешь нужен какой-то кеш?

Есть объект Счет. Рассматриваем вариант, когда счет уже есть в БД и мы открываем карту счета, чтобы сделать какие-то изменения.
В карте счета есть несколько вкладок. На главной вкладке есть панель поиска, с помощью которой можно к счету добавлять дочерние счета. С помощью этой панели мы нашли дочерние счета, которые мы можем добавить к этому счету.
Мы добавляем дочерний счет к счету с помощью кнопки добавить. Изменения в базу не должны ложиться, т.к. для этого есть кнопка Сохранить.
Соотвественно вопрос: "Где ты предлагаешь хранить такие объекты?"

В случае рекомендаций микрософта — время жизни контекста = запрос, получается этот добавленный счет умрет вместе с запросом.

G>Ест подозрение что ты что-то неправильно делаешь ибо кеши крайне плохо работают при изменении. В основном кеши используются для приближения данных к потребителю. Чтобы пользователь не отправлял запрос на сайт, чтобы веб-приложение не ходило в базу, чтобы база не читала данные с диска.

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

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

А>Есть объект Счет. Рассматриваем вариант, когда счет уже есть в БД и мы открываем карту счета, чтобы сделать какие-то изменения.
А>В карте счета есть несколько вкладок. На главной вкладке есть панель поиска, с помощью которой можно к счету добавлять дочерние счета. С помощью этой панели мы нашли дочерние счета, которые мы можем добавить к этому счету.
А>Мы добавляем дочерний счет к счету с помощью кнопки добавить. Изменения в базу не должны ложиться, т.к. для этого есть кнопка Сохранить.
А>Соотвественно вопрос: "Где ты предлагаешь хранить такие объекты?"
Предлагаю хранить их на клиентской стороне (грубо говоря не делать ничего), а переключение между вкладками сделать на JS. При нажатии "сохранить" изменения попадут на сервер и сохранятся.

Здравствуйте, Аноним, Вы писали:
А>В случае рекомендаций микрософта — время жизни контекста = запрос, получается этот добавленный счет умрет вместе с запросом.

Можно сериализовывать+кодировать в base64 данные и перекидывать их между клиентом и сервером в скрытом поле.

Здравствуйте, gandjustas, Вы писали:

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

А>>Есть объект Счет. Рассматриваем вариант, когда счет уже есть в БД и мы открываем карту счета, чтобы сделать какие-то изменения.
А>>В карте счета есть несколько вкладок. На главной вкладке есть панель поиска, с помощью которой можно к счету добавлять дочерние счета. С помощью этой панели мы нашли дочерние счета, которые мы можем добавить к этому счету.
А>>Мы добавляем дочерний счет к счету с помощью кнопки добавить. Изменения в базу не должны ложиться, т.к. для этого есть кнопка Сохранить.
А>>Соотвественно вопрос: "Где ты предлагаешь хранить такие объекты?"
G>Предлагаю хранить их на клиентской стороне (грубо говоря не делать ничего), а переключение между вкладками сделать на JS. При нажатии "сохранить" изменения попадут на сервер и сохранятся.

ID добавленных, но пока не "прицепленных" счетов в хидден филды пихать, чтобы при нажатии на Сохранить знать что добавилось?

а как тогда отрисовыввать формы на других вкладках при переходе на них с помощью жаваскрипта?
Сейчас при клике на другую вкладку идет Get запрос.

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

А>Здравствуйте, gandjustas, Вы писали:

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

А>>>Есть объект Счет. Рассматриваем вариант, когда счет уже есть в БД и мы открываем карту счета, чтобы сделать какие-то изменения.
А>>>В карте счета есть несколько вкладок. На главной вкладке есть панель поиска, с помощью которой можно к счету добавлять дочерние счета. С помощью этой панели мы нашли дочерние счета, которые мы можем добавить к этому счету.
А>>>Мы добавляем дочерний счет к счету с помощью кнопки добавить. Изменения в базу не должны ложиться, т.к. для этого есть кнопка Сохранить.
А>>>Соотвественно вопрос: "Где ты предлагаешь хранить такие объекты?"
G>>Предлагаю хранить их на клиентской стороне (грубо говоря не делать ничего), а переключение между вкладками сделать на JS. При нажатии "сохранить" изменения попадут на сервер и сохранятся.

А>ID добавленных, но пока не "прицепленных" счетов в хидден филды пихать, чтобы при нажатии на Сохранить знать что добавилось?

А>а как тогда отрисовыввать формы на других вкладках при переходе на них с помощью жаваскрипта?
А>Сейчас при клике на другую вкладку идет Get запрос.
Используй MVVM в JS. напрмиер knockout

Здравствуйте, gandjustas, Вы писали:

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

А>>Здравствуйте, gandjustas, Вы писали:

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

А>>>>Есть объект Счет. Рассматриваем вариант, когда счет уже есть в БД и мы открываем карту счета, чтобы сделать какие-то изменения.
А>>>>В карте счета есть несколько вкладок. На главной вкладке есть панель поиска, с помощью которой можно к счету добавлять дочерние счета. С помощью этой панели мы нашли дочерние счета, которые мы можем добавить к этому счету.
А>>>>Мы добавляем дочерний счет к счету с помощью кнопки добавить. Изменения в базу не должны ложиться, т.к. для этого есть кнопка Сохранить.
А>>>>Соотвественно вопрос: "Где ты предлагаешь хранить такие объекты?"
G>>>Предлагаю хранить их на клиентской стороне (грубо говоря не делать ничего), а переключение между вкладками сделать на JS. При нажатии "сохранить" изменения попадут на сервер и сохранятся.

А>>ID добавленных, но пока не "прицепленных" счетов в хидден филды пихать, чтобы при нажатии на Сохранить знать что добавилось?

А>>а как тогда отрисовыввать формы на других вкладках при переходе на них с помощью жаваскрипта?
А>>Сейчас при клике на другую вкладку идет Get запрос.
G>Используй MVVM в JS. напрмиер knockout


Спасибо! почитаю.

2 попутных вопроса:
1. А как тогда быть потом с валидацией страницы при серверной обработке?
т.е. вьюстейт придет другой, нежели ушел
2. Если канал http какие методы защиты данных от подмены использовать (ведь все пойдет в json, насколько я понял) ?

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

А>Здравствуйте, gandjustas, Вы писали:

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

А>>>Здравствуйте, gandjustas, Вы писали:

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

А>>>>>Есть объект Счет. Рассматриваем вариант, когда счет уже есть в БД и мы открываем карту счета, чтобы сделать какие-то изменения.
А>>>>>В карте счета есть несколько вкладок. На главной вкладке есть панель поиска, с помощью которой можно к счету добавлять дочерние счета. С помощью этой панели мы нашли дочерние счета, которые мы можем добавить к этому счету.
А>>>>>Мы добавляем дочерний счет к счету с помощью кнопки добавить. Изменения в базу не должны ложиться, т.к. для этого есть кнопка Сохранить.
А>>>>>Соотвественно вопрос: "Где ты предлагаешь хранить такие объекты?"
G>>>>Предлагаю хранить их на клиентской стороне (грубо говоря не делать ничего), а переключение между вкладками сделать на JS. При нажатии "сохранить" изменения попадут на сервер и сохранятся.

А>>>ID добавленных, но пока не "прицепленных" счетов в хидден филды пихать, чтобы при нажатии на Сохранить знать что добавилось?

А>>>а как тогда отрисовыввать формы на других вкладках при переходе на них с помощью жаваскрипта?
А>>>Сейчас при клике на другую вкладку идет Get запрос.
G>>Используй MVVM в JS. напрмиер knockout


А>Спасибо! почитаю.

А>2 попутных вопроса:
А>1. А как тогда быть потом с валидацией страницы при серверной обработке?
А>т.е. вьюстейт придет другой, нежели ушел
Так у вас webforms?
Тогда все совсем просто, сохранение в context происходит при нажатии кнопки. Так везде и делается, все равно двустороннй байндинг не поддерживается.
Фактически сами объекты будут храниться во viewstate.

А>2. Если канал http какие методы защиты данных от подмены использовать (ведь все пойдет в json, насколько я понял) ?
Ну вообще-то втроенные ViewStateMac (кстати при использовании UpdatePanel надо отключать)