Здравствуйте, Ocenochka, Вы писали:
O>Не очень понимаю как отслеживать изменения. Допустим на клиенте грид с коллекцией объектов. При редактировании в отдельную коллекцию складывать отредактированные объекты? А как порядок редактирования учитывать?
Вы видимо невнимательно прочитали тему. Либо реализовывать флаг IsDirty в самом бизнес-объекте (базовом классе), либо использовать Wrapper, который будет отслеживать изменения обертываемого объекта и реализовывать флаг IsDirty. Если нужно учитывать порядок редактирования — это отдельная задача, но лично мне никогда не нужно было учитывать порядок редактирования. Вы уверены что вы заранее не усложняете задачу зачем-то?
O>>> — возникает необходимость хранить список изменений или передавать все потенциально измененные объекты;
MC>>Смотрите тему http://rsdn.ru/forum/design/3367411.flat.aspxАвтор: MozgC
Дата: 21.04.09
O>Прочитал. Понял не много и легче не стало.
Может стоит еще раз внимательно прочитать? Я серьезно.
O>Врапперы над сущностями и их коллекциями — это круто. Не совсем представляю как это будет в случае с несколькими клиентами.
Видимо у каждого клиента будет своя коллекция обернутых объектов.
O>DataSet то же не хотелось бы, не то, чтобы я сильно религиозен, но мозги придется перекраивать сновательно.
В принципе датасеты вариант, но лично мне кажется что они провоцируют дублирование логики, а так же вынос логики в presentation. К тому же нетипизированные датасеты неудобны отсутствием типизации, а типизированные датасеты дают мало контроля, т.к. все генерируется и перегенерируется автоматически.
O>А последовательность изменений не учитывать? Если пятая операция из 10 не прошла, то, на мой взгляд, логично откатить все 10. Соответственно, пользователю прдется переделывать все 10.
Ну это зависит от задачи. Если мы принимаем 10 заказов от разных клиентов (через веб-сервис к примеру) и принялись только 5, после чего возникла ошибка — то откатывать все не нужно, просто запросить те которые не принялись и попытаться их сохранить. Если же действия должны быть "атомарными", то да, откатываем все 10. Но видимо у нас с вами тут какое-то недопонимание, потому как я не понимаю, почему пользователю придется переделывать все 10? К примеру пользователь открывает форму с разными полями для редактирования и гридом, что-то там изменяет и жмет сохранить. Если где-то косяк (к примеру ошибка валидации или ваша любимая коллизия), то пользователю просто сообщится о конкретной ошибке ("Product price can not exceed $100000"), на форме же останутся изменения сделанные пользователем. Пользователь исправляет что нужно и жмет Сохранить еще раз.
Если же вы про облом операции именно по причине коллизии, то тут надо сначала знать, что должно происходить в случае коллизии? Может просто молча должны записаться изменения пользователя (на мой взгляд зачастую это вполне допустимо), или же надо сообщить пользователю о том что в БД уже етсь измененная версия объекта и спросить хочет ли он ее перезаписать? Или же надо перечитать (или просто отдельно показать) измененный объект из БД? Или надо все перечитать? Это вы должны сначала вместе с экспертами предметной области решить как должна вести себя система.
O>>> б) либо на каждое действие пользователя включать курсор "песочные часы" и отправлять изменения на сервер — в принципе,
O>>> не вижу проблем, но почему-то не часто его встречаю (а может реже замечаю) — если есть проблемы, хотелось бы их узнать.
MC>>Это просто неправильно так делать.
O>Не правильно делать категоричные заявления без аргументов 
Ясно, что производительность и отзывчивость могут пострадать, если клиентов будет много, а сервер далеко, но есть подозрение, что дело не в этом.
И в этом тоже. Вы вообще искренне считаете что нормально отправлять изменения и сохранять их на сервере по каждому чиху пользователя? А если он решит отменить изменения?
