Добавянето на автоматични свойства ще повлияе ли на отдалеченото?

Имаме огромно приложение 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; }
}

промяна на формата за сериализация, прекъсване на съвместимостта с по-стари клиенти?


c# serialization remoting
person Chris Doggett    schedule 09.02.2009    source източник

Отговори (1)


arrow_upward
1
arrow_downward

Важна редакция: това трябва да е съвместимо и да позволява обвързване?

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 използва BinaryFormatterm, който (без индивидуална реализация ISerializable) използва имената на полетата. Използването на автоматични свойства прекъсва имената на полетата.

Докато актуализирате клиент и сървър едновременно, трябва да работи. Друга възможност е да използвате сериализация, независима от името, като protobuf-net. Мога да дам пример, ако искате (поддържа ISerializable използване).

(между другото, добавянето на свойства не трябва да не засяга BinaryFormatter, тъй като е базирано на поле)

Както е поискано, ето пример за използване на protobuf-net за управление на отдалечено сериализиране (взето директно от един от моите единични тестове); имайте предвид, че това също ще бъде несъвместимо, докато клиентът и сървърът не се съгласят, но трябва да издържа на промени след това (предназначено е да бъде много разширимо). Имайте предвид, че има много начини за използването му - или изрична нотация на член (като договори за данни), или неявни полета (като BinaryFormatter) и т.н. (всичко между тях)... това е само един начин от използването му:

[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(...)] дефинира полета (с уникални идентификационни маркери). Както вече беше посочено, той също може да направи изводи за тях, но е по-безопасно (по-малко крехко) да бъде изрично.

person Marc Gravell    schedule 09.02.2009
comment
Помага, че сте авторът на protobuf-net ;) - person Joel Coehoorn; 09.02.2009
comment
Е да. Но е безплатно, така че това не е маркетинг. Факт е, че google-bods решиха много проблеми с техния формат на кабела. Щастлив съм, че мога да предложа тези корекции, достъпни за потребителската база на .NET (отново безплатно). - person Marc Gravell; 09.02.2009
comment
Бих искал да видя пример. Благодаря за бързата реакция. - person Chris Doggett; 09.02.2009