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

>Представьте ситуацию: расплачиваясь за покупку, Вы видите одну сумму, но с карточки снимается другая сумма. Либо Вы покупаете один товар, но доставляют другой... Неприятно, но по замыслу разработчика виноваты именно Вы! Надо было чаще обновлять форму!
Я такого не говорил. Решение этой проблемы давно всем известно, и smart client тут не причем. Данные типа цены товара копируются в заказ.

>Да, можно с этим мириться или нет, решать будет разработчик (если в функциональных требованиях это не оговорено). Только в основе решения должно лежать не то, что плохо лишний раз гонять данные, а то, в каком положении может оказаться пользователь системы.
Разработчик должен выполнять оба требования и производительность, и отсутствие таких казусов. Причем оба требования обязательные. Если приложение будет тормозить, то им даже не начнут пользоваться. А если будут редкие казусы, то могут не сразу отказаться, а просто заасайнить багу .

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

>Я не знаю, будет ли Product единственным объектом, подгружаемым с сервера по изменению Lookup-а.
Допустим один объект Product.

>Если подгружаемый Pruduct один, то мерж будет тривиальный.
Тривиальный говорите? а если Product с таким идентификатор уже присутствует в датасете (присоединен к другому OrderItem) и отличается от вновь пришедшего, что будет делать мердж датасетов? там какие-то флажки в аргументах кажется есть? Старый продукт тоже останется в датасете, и, возможно, будет мешаться при следующих мерджах. А в случае простого графа без Identity Map мерджа вообще нет ! Причем, если мы наткнулись на редкую ситуация, когда с сервера приходит обновленная версия продукта, то для пользователя это выгладит вполне естественно – часть формы обновилось, а часть нет. А в случае с датасетами вы делаете непонятную для пользователя операции -- мердж. Кстати, вы еще должны корректно обновить пользовательский интерфейс, чтобы отобразить все что вы там намерджели, а датасеты не поддерживают натификпацию.

>Если Product связан с другими сущностями, которые могут быть уже подкачаны на клиент, то мерж усложняется, не зависимо от основы DTO (DataSet или граф объектов).
Повторюсь, в случае графа мерджа нет.

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

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

>>Представьте ситуацию: расплачиваясь за покупку, Вы видите одну сумму, но с карточки снимается другая сумма. Либо Вы покупаете один товар, но доставляют другой... Неприятно, но по замыслу разработчика виноваты именно Вы! Надо было чаще обновлять форму!
AP>Я такого не говорил. Решение этой проблемы давно всем известно, и smart client тут не причем. Данные типа цены товара копируются в заказ.
Такие данные копируются в заказ для того чтобы сервер мог проверить соответсвие этих данных. Но я говорил о том, что данные, показываемые пользователю хотя бы на одном скрине, не должны вызывать противоречий. Это к ситуации, когда на клиенте оказывается более одной актуальной копии продукта Разработчик знает, где у него в программе самая актуальная копия (или догадывается), а неискушенный пользователь запутается, если на экране будет противоречивая информация.

>>Да, можно с этим мириться или нет, решать будет разработчик (если в функциональных требованиях это не оговорено). Только в основе решения должно лежать не то, что плохо лишний раз гонять данные, а то, в каком положении может оказаться пользователь системы.
AP>Разработчик должен выполнять оба требования и производительность, и отсутствие таких казусов. Причем оба требования обязательные. Если приложение будет тормозить, то им даже не начнут пользоваться. А если будут редкие казусы, то могут не сразу отказаться, а просто заасайнить багу .
Этот вопрос не стоит обсуждать заочно. Возможно что накладные расходы на передачу данных малы по сравнению с удаленным вызовом + обращением к БД. Кстати, это Ваше предложение (гнать данные для мержа на сервер).

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

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

>>Если подгружаемый Pruduct один, то мерж будет тривиальный.
AP>Тривиальный говорите? а если Product с таким идентификатор уже присутствует в датасете (присоединен к другому OrderItem) и отличается от вновь пришедшего, что будет делать мердж датасетов?
Смержит
AP>там какие-то флажки в аргументах кажется есть?
Какие такие флажки в аргументах?
AP>Старый продукт тоже останется в датасете, и, возможно, будет мешаться при следующих мерджах.
Если установлены ключевые поля, то при мерже обновится соответствующая запись, новой создано не будет.
AP>А в случае простого графа без Identity Map мерджа вообще нет !
В случае, когда Product возвращается с сервера одним экземпляром — то обойдется только подменой ссылки, но если Product связан с чем-то еще — мержить графы будет не просто.
AP>Причем, если мы наткнулись на редкую ситуация, когда с сервера приходит обновленная версия продукта, то для пользователя это выгладит вполне естественно – часть формы обновилось, а часть нет.
Вам решать, естественно ли это. Может в Вашем случае нужно чтобы пользователь одновременно видел несколько версий продуктов?
AP>А в случае с датасетами вы делаете непонятную для пользователя операции -- мердж. Кстати, вы еще должны корректно обновить пользовательский интерфейс, чтобы отобразить все что вы там намерджели, а датасеты не поддерживают натификпацию.
Граф объектов для пользователя такой же темный лес как DataSet с мержем! Не будете же Вы пользователям разжевывать механику подмены ссылок? Нотификацию DataSet-ы поддерживают, да и вызывать Refresh у соответствующих контролок — тоже не проблема.

>>Если Product связан с другими сущностями, которые могут быть уже подкачаны на клиент, то мерж усложняется, не зависимо от основы DTO (DataSet или граф объектов).
AP>Повторюсь, в случае графа мерджа нет.
Предположим, что Product ссылается на Manufacture. И в новой порции данных они идут парой. В старой порции есть и Product и Manufacture, причем на тот экземпляр Manufacture ссылаются другие Product-ы. Если вас не будет пугать наличие в одном графе нескольких экземпляров одной Manufacture и одного Product, то придется графы мержить. И даже в случае, когда Product один, нет гарантии, что заменой одной ссылки в графе Вы полностью исключите наличие в графе других экземпляров того же продукта. В общем случае придется проанализировать ВСЕ места, где будут ссылки на данный конкретный Product, который Вы хотите в графе заменить.
Как будет называться такая операция, если не merge? А общий случай мержа графов объектов запросто по сложности не уступит реализации GC!

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

>Нотификацию DataSet-ы поддерживают
Вы уверены, что после мерджа DataSeet-ов всё корректно обновиться на UI-е на WPF? (речь про нотификацию шла именно в этом контексте, а не просто абстрактная нотификация. Конкретно WPF не упоминался, но механизм доставки данных как раз и не должен быть сильно завязан на технологию UI-я).

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

AP>>Тривиальный говорите? а если Product с таким идентификатор уже присутствует в датасете (присоединен к другому OrderItem) и отличается от вновь пришедшего, что будет делать мердж датасетов?
>Смержит
да мердж мерджит . Но я задавал вопрос в надежде услышать детали, как он это делает.

AP>>там какие-то флажки в аргументах кажется есть?
>Какие такие флажки в аргументах?
Это я задавал вопрос . Я имел ввиду PreserveChanges http://msdn.microsoft.com/en-us/library/aszytsd8.aspx

>В случае, когда Product возвращается с сервера одним экземпляром — то обойдется только подменой ссылки, но если Product связан с чем-то еще — мержить графы будет не просто.
Предлагаю иногда спускаться с абстрактных вершин и приводить конкретные примеры для подтверждения своих утверждений. Например, если Product связан с ProductCategory, то все так же просто, просто меняется ссылка.

>мержить графы будет не просто
Никто и не говорил, что будет просто в абсолютном смысле , сейчас мы сравниваем два подхода DataSet-ы и простой граф объектов (ссылки объектов друг на друга).

>Вам решать, естественно ли это. Может в Вашем случае нужно чтобы пользователь одновременно видел несколько версий продуктов?
В каком в моем случае? Во многих проектах (если не во всех), в которых я учавствовал(ю), да это приемлемо.

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

>Граф объектов для пользователя такой же темный лес как DataSet с мержем! Не будете же Вы пользователям разжевывать механику подмены ссылок?
О графе объектов пользователь, конечно, не задумывается, но вот ссылку на продукт в строке заказа он вполне ясно себе представляет (помогает ему в этом то, что происходит на экране).

>Не будете же Вы пользователям разжевывать механику подмены ссылок?
Смена значения в Lookup-е на пользовательском интерфейсе хорошо согласуется со сменой ссылки в строке заказа (в объектах). Поэтому дополнительные объяснения не требуются.

>Предположим, что Product ссылается на Manufacture. И в новой порции данных они идут парой. В старой порции есть и Product и Manufacture, причем на тот экземпляр Manufacture ссылаются другие Product-ы. Если вас не будет пугать наличие в одном графе нескольких экземпляров одной Manufacture и одного Product, то придется графы мержить. И даже в случае, когда Product один, нет гарантии, что заменой одной ссылки в графе Вы полностью исключите наличие в графе других экземпляров того же продукта. В общем случае придется проанализировать ВСЕ места, где будут ссылки на данный конкретный Product, который Вы хотите в графе заменить.
Как будет называться такая операция, если не merge? А общий случай мержа графов объектов запросто по сложности не уступит реализации GC!
Тк я ж про это и говорил, объекты под Lookup-оп обычно только для чтения, поэтому несколько экземпляров таких объектов не вызывают проблем.

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

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

AP>Вы уверены, что после мерджа DataSeet-ов всё корректно обновиться на UI-е на WPF? (речь про нотификацию шла именно в этом контексте, а не просто абстрактная нотификация. Конкретно WPF не упоминался, но механизм доставки данных как раз и не должен быть сильно завязан на технологию UI-я).
Уверен. Даже специально проверил. Отображается. А за "всё" и "корректно" зуб не дам

        public Form1()
        {
            InitializeComponent();

            dataSet11.DataTable1.AddDataTable1Row("n0", 0);
            listBox1.DisplayMember = "Name";
            listBox1.DataSource = dataSet11.DataTable1;            
        }

        private void button1_Click(object sender, EventArgs e)
        {
            DataSet1 ds = new DataSet1();
            ds.DataTable1.AddDataTable1Row("n1", 0);
            ds.DataTable1.AddDataTable1Row("n2", 1);
            dataSet11.Merge(ds);
        }

Здесь DataSet1 — Тип типизивованного датасета с оной таблицей и двумя полями в ней. Первое поле строковое "Name", второе целое PrimaryKey.

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

AP>да мердж мерджит . Но я задавал вопрос в надежде услышать детали, как он это делает.
Reflector в руки и бог в помощь! И советую запастись терпением ))) Есть догадка что код мерджа датасетов занимает около 1/4 всего кода фреймворка (шутка). Предположительно мердж сопоставляет записи по ключевым полям. Дальше дело техники.

>>Какие такие флажки в аргументах?
AP>Это я задавал вопрос . Я имел ввиду PreserveChanges http://msdn.microsoft.com/en-us/library/aszytsd8.aspx
Понял. Но там же все написано. Что от меня требуется?

>>В случае, когда Product возвращается с сервера одним экземпляром — то обойдется только подменой ссылки, но если Product связан с чем-то еще — мержить графы будет не просто.
AP>Предлагаю иногда спускаться с абстрактных вершин и приводить конкретные примеры для подтверждения своих утверждений. Например, если Product связан с ProductCategory, то все так же просто, просто меняется ссылка.
С допущением что в графе объектов могут быть избыточные дублирующие объекты — действительно так же все просто.

>>Вам решать, естественно ли это. Может в Вашем случае нужно чтобы пользователь одновременно видел несколько версий продуктов?
AP>Какая-то детсадовская отговорка, типа у вас больше знаний о проект, и только вы можете выбрать правильное решение. У вас разве с опытом не накапливаются экспертные знания, с помощью которых, задав пару тройку вопросов, вы уже можете предложить правильное решение?
Да, я все еще пытаюсь. Экспертные знания — это конечно круто, но я стараюсь делать так, чтобы перед пользователем, хотя бы в пределах одной формы не было противоречивых данных, и чтобы программист не гадал, который экземпляр ProductCategory правильный, а который нет (даже если они только для чтения).

AP>Тк я ж про это и говорил, объекты под Lookup-оп обычно только для чтения, поэтому несколько экземпляров таких объектов не вызывают проблем.
Ну хорошо. Lookpup не вызывает проблем. Где-то кроме Lookup-а они могут быть?
Лично меня напрягает уже то, что здесь приходится оперировать данными, прочитанными в разных транзакциях. Это не важно при чтении справочных данных, которые забиваются один раз и меняются только в дауне. Как читать все остальное — решать надо по месту.
Мэй би я параноик...

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

AP>Теперь о том, как данные будут приходить обратно от клиента к серверу. На клиенте есть некий ClientContext. После десериализации объектов на клиенте, для каждого DTO объекта текущий ClientContext подписывается на изменения в DTO объекте. Пользователь редактирует данные, изменения попадают в DTO объекты, а ClientContext регистрирует у себя все изменения. После того, как пользователь поработал с данными, изменения, зарегистрированные в ClientContext, отправляются на сервер. На сервере эти изменения попадают в объекты LINQ to SQL.

Похоже вас несщадно критикуют на месте работы.
Если не секрет — что за организации из раза в раз разрабатывают новые клиент-серверные приложения — вы ISV или это конкретная разработка?

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

Извиняюсь, что долго не заглядывал в эту тему.

>Похоже вас несщадно критикуют на месте работы.
Не понял вашей шутки.

>Если не секрет — что за организации из раза в раз разрабатывают новые клиент-серверные приложения — вы ISV или это конкретная разработка?
Про компанию рассказывать пока не вижу смысла .

>клиент-серверные приложения
В этом треде вроде речь о трехзвенке -- смарт клиенте.

>что за организации из раза в раз разрабатывают новые клиент-серверные приложения
Вы считаете, что уже никто ничего нового не пишет? Да, согласен, что уже много чего написано. Но вот небольшой вопрос. Зачем Microsoft вводит такие новые технологи, как WPF, LINQ и т.д.? не для старых же приложений?