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

AP>Метод GetOrder возвращает на клиента граф связанных объектов. В методе GetOrder идет копирование данных из LINQ to SQL в TDO объекты, есть предположение, что для этого можно написать общие методы, принимающие лямбда выражения в качестве аргументов, т.е. такое ручное копирование с использованием общих методов.
Да, такое представляется возможным для автоматизации, но это не самое узкое место.

AP>На клиенте есть некий ClientContext. После десериализации объектов на клиенте, для каждого DTO объекта текущий ClientContext подписывается на изменения в DTO объекте. Пользователь редактирует данные, изменения попадают в DTO объекты, а ClientContext регистрирует у себя все изменения. После того, как пользователь поработал с данными, изменения, зарегистрированные в ClientContext, отправляются на сервер. На сервере эти изменения попадают в объекты LINQ to SQL.
Здесь меня немного пугает обилие кода, связанным с поддержкой сообщений об изменении DTO объектов и довольно плотной подпиской на все сообщения ClientContext-ом. Накопление истории изменений и применение ее на сервере тоже может оказаться громоздким. Если кроме ClientContext-а, кому-то еще будут нужны сообщения об изменениях объектов, то это может окупиться. Если нет — могу предложить вариант, где ClaimDTO и граф объектов являются надстройкой над типизированным DataSet-ом. Если объекты будут хранить состояния в соответствующих DataRow объектах, то никакой подписки на изменения можно вообще не делать и вместо истории изменений на сервере разгребать изменения в переданном DataSet-е. При использовании LINQ to SQL, такой DataSet вообще не обязан повторять схему БД, может содержать любую избыточную информацию и служить буфером для изменений в ClaimDTO или в схеме БД.

Так же могу порекомендовать обратить внимание на "Entity Framework" и его возможность к транспортировке объектов отдельно от контекста с последующим сохранении изменений (здесь). В этом случае сами DTO объекты могут быть переданы на сервер в качестве изменений.