копирую в ViewState объект DataTable-

ViewState["fields"] = dt

затем достаю объект из ViewState —

dt = ViewState["fields"]

а теперь вопрос- почему при удалении строк из dt также удаляются строки из ViewState ? догадываюсь что копируется ссылка, а как правильно скопировать чтобы создалась копия объекта?

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

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

dt.Clone?

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

L>dt.Clone?

Тогда уж dt.Copy(). Clone не копирует данные, только структуру

Здравствуйте, Sergey J. A., Вы писали:

L>>dt.Clone?

SJA>Тогда уж dt.Copy(). Clone не копирует данные, только структуру

Сорри

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

А>копирую в ViewState объект DataTable-

Не делайте так. Вы сами себе яму роете. HTTP-канал все еще является узким местом — чаще всего не стоит так пессимизировать свое приложение.

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

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

А>>копирую в ViewState объект DataTable-

Кэр>Не делайте так. Вы сами себе яму роете. HTTP-канал все еще является узким местом — чаще всего не стоит так пессимизировать свое приложение.

а как лучше делать? каждый раз заполнять DataTable?

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

А>а как лучше делать? каждый раз заполнять DataTable?

Если получаете запрос из базы — получайте каждый раз запрос из базы. Оптимизируйте запрос, если вы думаете, что он выполняется долго (это должно означать, что он выполняется сравнимо долго с другими частями приложения, а не то, что вам просто захотелось "пооптимизировать в этом месте"). Также можно подумать о том, как можно закэшировать результат всего http-запроса. Т.е. сделать так, чтобы клиент вообще не приходил на сервер за запросом раньше чем нужно или сервер вообще не обрабатывал запрос, отдавая результат из кэша IIS.

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

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

А>>а как лучше делать? каждый раз заполнять DataTable?

Кэш. И не обязательно HTTP-кэш. Кэш уровня DAO или Service например, если конечно вы используете трёхуровневую архитектуру.

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

А>>а как лучше делать? каждый раз заполнять DataTable?

Кэр>Если получаете запрос из базы — получайте каждый раз запрос из базы.

А если мы редактируем данные, как быть с concurrency?

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

А>>>а как лучше делать? каждый раз заполнять DataTable?
Кэр>>Если получаете запрос из базы — получайте каждый раз запрос из базы.
L>А если мы редактируем данные, как быть с concurrency?

То есть, при редактировании данных, во избежании проблем с concurrency ничего лучшего кроме сохранения объекта DataTable во ViewState нельзя придумать

Главное в ответе — не то, как можно решить проблему (это тема отдельного разговора), а то, что не очень хорошо решать проблему так, как делает автор.

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

А>>>>а как лучше делать? каждый раз заполнять DataTable?
Кэр>>>Если получаете запрос из базы — получайте каждый раз запрос из базы.
L>>А если мы редактируем данные, как быть с concurrency?

_FR>То есть, при редактировании данных, во избежании проблем с concurrency ничего лучшего кроме сохранения объекта DataTable во ViewState нельзя придумать

Например?

_FR>Главное в ответе — не то, как можно решить проблему (это тема отдельного разговора), а то, что не очень хорошо решать проблему так, как делает автор.

При отсутствии альтернатив даже очень плохое решение — лучшее из всех возможных (альтернатив-то нет)

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

_FR>>То есть, при редактировании данных, во избежании проблем с concurrency ничего лучшего кроме сохранения объекта DataTable во ViewState нельзя придумать

L>Например?

всё что угодно, кроме DataTable, так как не раз уже обсуждался оверхед, связанный с сериализацией в xml этого добра.

_FR>>Главное в ответе — не то, как можно решить проблему (это тема отдельного разговора), а то, что не очень хорошо решать проблему так, как делает автор.

L>При отсутствии альтернатив даже очень плохое решение — лучшее из всех возможных (альтернатив-то нет)

Я не знаток веб-технологий, но всё равно сомневаюсь, что альтернатив нет.

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

Кэр>>Если получаете запрос из базы — получайте каждый раз запрос из базы.
L>А если мы редактируем данные, как быть с concurrency?

Я думаю, что не понимаю, о какой проблеме с concurrency вы говорите. Потому что в том варианте, что я понимаю, сохранение DataTable в ViewState только усиливает проблемы с concurrency.

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

Кэр>>>Если получаете запрос из базы — получайте каждый раз запрос из базы.
L>>А если мы редактируем данные, как быть с concurrency?

Кэр>Я думаю, что не понимаю, о какой проблеме с concurrency вы говорите.

Стандартный подход работы с concurrency: при начале редактирования сохраняем оригинал строки, которую редактируем, во ViewState-е, при сохранении — вытаскиваем из ViewState-а, обновляем значениями из UI и коммитим в базу. При наличии timestamp поля в таблице, если кто-то другой обновил запись до нас, то вылетит ConcurrencyException.

Кэр>Потому что в том варианте, что я понимаю, сохранение DataTable в ViewState только усиливает проблемы с concurrency.

Альтернатива — это вручную проверять значение в базе, а для этого придется хранить оригинальную версию (поле) во все том же ViewState-е, и или 1) перечитывать запись из базы или 2) при сохранении воссоздавать оригинальную запись, аттачить ее к таблице, выставлять значение версии вручную и потом коммитить. Оба решения не без недостатков.

Если у вас есть решение для работы с concurrency лучше перечисленных выше,с удовольствие выслушаю.

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

Кэр>>Потому что в том варианте, что я понимаю, сохранение DataTable в ViewState только усиливает проблемы с concurrency.
L>Альтернатива — это вручную проверять значение в базе, а для этого придется хранить оригинальную версию (поле) во все том же ViewState-е, и или 1) перечитывать запись из базы или 2) при сохранении воссоздавать оригинальную запись, аттачить ее к таблице, выставлять значение версии вручную и потом коммитить. Оба решения не без недостатков.
L>Если у вас есть решение для работы с concurrency лучше перечисленных выше,с удовольствие выслушаю.

Не сомневаюсь в том, что

1. в NHibernate есть решение;
   
2. что это решение не связано с сохранение объекта DataTable во ViewState.

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

Кэр>>>Потому что в том варианте, что я понимаю, сохранение DataTable в ViewState только усиливает проблемы с concurrency.
L>>Альтернатива — это вручную проверять значение в базе, а для этого придется хранить оригинальную версию (поле) во все том же ViewState-е, и или 1) перечитывать запись из базы или 2) при сохранении воссоздавать оригинальную запись, аттачить ее к таблице, выставлять значение версии вручную и потом коммитить. Оба решения не без недостатков.
L>>Если у вас есть решение для работы с concurrency лучше перечисленных выше,с удовольствие выслушаю.

_FR>Не сомневаюсь в том, что
_FR>

_FR>
1. в NHibernate есть решение;
   _FR>
2. что это решение не связано с сохранение объекта DataTable во ViewState.
   _FR>

Мне кажется, в ветке об обсуждении concurrency для datatable-ов предлагать отказаться от datatable-ов, это как бы не совсем... гм адекватный ответ.

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

L>Мне кажется, в ветке об обсуждении concurrency для datatable-ов предлагать отказаться от datatable-ов, это как бы не совсем... гм адекватный ответ.

Это лишь пример того, что есть возможность использовать контейнер, отличный от DataTable. О чём изначально и говорилось. А так же, насколько я помню, данные полей (в том числе, и timestamp, и оригинальные значения полей, если timestamp-а нет) при редактировании объекта сохраняются "внутри" полей пересылаемой формы. То есть опять же проблем с конкаренси можно избежать.

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

L>>Мне кажется, в ветке об обсуждении concurrency для datatable-ов предлагать отказаться от datatable-ов, это как бы не совсем... гм адекватный ответ.

_FR>Это лишь пример того, что есть возможность использовать контейнер, отличный от DataTable. О чём изначально и говорилось. А так же, насколько я помню, данные полей (в том числе, и timestamp, и оригинальные значения полей, если timestamp-а нет) при редактировании объекта сохраняются "внутри" полей пересылаемой формы. То есть опять же проблем с конкаренси можно избежать.

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

Здравствуйте, Lloyd, Вы писали:
L>Не совсем понимаю, что значит "сохраняются "внутри" полей пересылаемой формы". Пожешь подробнее расписать, что ты имеешь в виду?
Имеется в виду, что значения полей формы обычно уезжают клиенту дважды: 1 раз в виде атрибута value, и еще раз в виде viewstate.
Делается это для того, чтобы можно было корректным образом отработать событие onchange во время постбека.

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

S>Здравствуйте, Lloyd, Вы писали:
L>>Не совсем понимаю, что значит "сохраняются "внутри" полей пересылаемой формы". Пожешь подробнее расписать, что ты имеешь в виду?
S>Имеется в виду, что значения полей формы обычно уезжают клиенту дважды: 1 раз в виде атрибута value, и еще раз в виде viewstate.
S>Делается это для того, чтобы можно было корректным образом отработать событие onchange во время постбека.

А что толку? Оритинальное значение-то все равно не получить.
А что тогда с timestamp-ом. Он-то куда уезжает?