Повлияет ли добавление автоматических свойств на удаленное взаимодействие? - PullRequest
Новая
       7

Повлияет ли добавление автоматических свойств на удаленное взаимодействие?

2 голосов
/ 09 февраля 2009

У нас есть огромное клиент-серверное приложение WinForms, которое использует удаленное взаимодействие .NET для передачи DAO между уровнями, что имеет несколько проблем.

  1. Все DAO были определены для использования полей вместо свойств задолго до того, как я сюда попал, и вы не можете привязать поля к элементам управления.
  2. Добавление полей или свойств в DAO изменяет формат сериализации, требуя двойного развертывания клиент / сервер, что для нас гораздо сложнее, чем развертывание клиента или сервера (нам приходится работать с расписанием врачей, чтобы минимизировать время простоя) .

Используя простой, надуманный и вымышленный пример, вы могли бы изменить объект следующим образом: 

public class Employee
{
    public int ID;
    public string Name;
    public DateTime DateOfBirth;
}

к этому: 

public class Employee
{
    public int ID { get; set; }
    public string Name { get; set; }
    public DateTime DateOfBirth { get; set; }
}

изменить формат сериализации, нарушая совместимость со старыми клиентами?

1 Ответ

1 голос
/ 09 февраля 2009

Важное редактирование: это должно быть совместимо и разрешать связывание? 

public class Employee
{
    private int id;
    private string name;
    private DateTime dateOfBirth;
    public int ID { get {return id;} set {id = value;} }
    public string Name { get {return name;} set {name = value;} }
    public DateTime DateOfBirth { get {return dateOfBirth;}
         set {dateOfBirth = value;} }
}

Конечно, стоит попробовать, нет?

Да, это вызовет проблемы, если клиент / сервер не синхронизирован.

.NET remoting использует BinaryFormatterm, который (без специальной реализации ISerializable) использует имена полей. Использование автоматических свойств ломает имена полей.

Пока вы обновляете клиент и сервер одновременно, он должен работать. Другой вариант - использовать независимую от имени сериализацию, например protobuf-net . Я могу привести пример, если хотите (он поддерживает использование ISerializable).

(кстати, добавление свойств должно не влиять на BinaryFormatter, так как оно основано на полях)

По запросу, вот пример использования protobuf-net для управления удаленной сериализацией (взятой непосредственно из одного из модульных тестов ); обратите внимание, что это будет также несовместимым до тех пор, пока и клиент, и сервер не согласятся, но должны выдерживать изменения после этого (он предназначен для очень расширяемого). Обратите внимание, что существует множество способов его использования - либо явное обозначение члена (например, контракты данных), либо неявные поля (например, BinaryFormatter) и т. Д. (Все, что между ними) ... это всего лишь one способ его использования: 

[Serializable, ProtoContract]
public sealed class ProtoFragment : ISerializable
{
    [ProtoMember(1, DataFormat=DataFormat.TwosComplement)]
    public int Foo { get; set; }
    [ProtoMember(2)]
    public float Bar { get; set; }

    public ProtoFragment() { }
    private ProtoFragment(
        SerializationInfo info, StreamingContext context)
    {
        Serializer.Merge(info, this);
    }
    void  ISerializable.GetObjectData(
        SerializationInfo info, StreamingContext context)
    {
        Serializer.Serialize(info, this);
    }
}

Здесь 2 нижних метода удовлетворяют ISerializable и просто передают выполнение движку protobuf-net . [ProtoMember(...)] определяет поля (с уникальными идентификационными маркерами). Как уже говорилось, он также может выводить их, но более безопасно (менее хрупко) быть явным.

...