Служба WCF, которая занимается большими объектами

Question

Просмотр WCF в его использовании как способа выполнения RPC между удаленными ПК, вы можете просто отправить объект в качестве параметра метода. Это легко кодировать, но означает, что когда объект изменяется, вы отправляете все целиком, а также потенциально означает, что получатель должен иметь дополнительную логику, чтобы действовать только на измененные поля. Или вы можете иметь класс, который имеет один метод для каждого атрибута объекта. Этот детальный подход отлично подходит для производительности, если у вас большой класс и обычно вы меняете только один атрибут. Но кода для написания гораздо больше, и его нужно поддерживать каждый раз, когда объект получает другой атрибут.

Есть ли лучший подход, позволяющий избежать необходимости загружать методы копирования-вставки для каждого атрибута, но также отправлять только те атрибуты, которые действительно меняются? Можем ли мы автоматически генерировать методы службы WCF из класса / интерфейса или чего-то еще?

Например, скажем, у нас есть (псевдо) классы, и цель состоит в том, чтобы два приложения хотели синхронизировать людей (я добавляю сложный атрибут List, чтобы сделать его немного похожим на реальную жизнь):

class Pet
{
 String name;
 AnimalType type;
}

class Person
{
 int age;
 float height;
 string name;
 List<Pet> pets
}

Answer 1

Как бы вы ни делали, это будет накладные расходы. Вам решать, какой тип накладных расходов наиболее приемлем для вас. Возможные подходы:

1. Игнорировать проблему и всегда отправлять полную сущность. Сверхнормативные затраты здесь - это огромное количество отправляемых данных.
2. Используйте ADO.NET Data Services. Издержки здесь - это контекст данных, отслеживание изменений и общая «болтливость» всего этого.
3. Перепроектируйте ваши контракты, чтобы уменьшить объем передаваемых данных. Издержки здесь - дополнительная сложность интерфейса службы.

Пример варианта 3:

class Person {
    string Name;
    PersonalData PersonalData;
    MedicalData MedicalData;
    List<Pet> Pets;
}

class PersonalData {
    int Age;
    string SSN;
}

class MedicalData {
    float Weight;
    float Height;
}

class Pet {
    string Name;
    AnimalType Type;
}

interface IPerson {
    void Update(Person data, bool includePersonalData, bool includeMedicalData, bool includePets);
}

В клиентском коде, если вы не хотите обновлять медицинские данные, вы можете передать false методу обновления и не беспокоиться о создании объекта MedicalData в данных. Это сокращает сетевой трафик, поскольку соответствующий элемент в InfoSet будет отсутствовать.

Answer 2

Решение действительно зависит от ваших ограничений связывания.Если вы вынуждены использовать базовые Http-привязки, ADO.Net DataServices может быть лучшим подходом, как заявили Павел и Кристиан.Однако, если NetTcp и другие более сложные привязки (WS *) доступны, вы можете посмотреть на Надежный обмен сообщениями с заказанной доставкой.Вы можете разбить свои ответы на более мелкие куски и соединить их вместе на другом конце.Также обратите внимание на трансляцию в потоковом или буферизованном виде.Конечно, это требует гораздо больше работы, чем ADO.Net DataServices, но это делает его более увлекательным, не так ли?

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

Answer 3

WCF сам по себе этого не делает. Существует множество подходов для определения изменений, но в большинстве случаев это обязанность разработчиков.

Единственное предопределенное решение - ADO.NET DataServices. На самом деле это сервисная оболочка RESTful WCF для Entity Framework Datacontext от Microsoft. Честно говоря, вы можете использовать его не только с EF. На стороне клиента вы получаете контекст, который отслеживает изменения. Когда вы отправляете изменения, клиент отправляет только конкретные изменения. Но это ограничивает вас транспортом HTTP и сериализацией XML или JSON, что снижает производительность больших объектов.

Также может быть какое-то решение, управляемое событиями, когда вы отправляете команду на сервер с некоторыми метаданными.