создание личных данных членов в службе WCF

Question

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

Answer 1

Используйте ваши контракты с данными просто как DTO и расширьте их в коде, который выполняет обработку данных.

Примерно так:

[DataContract]
public class WCFDataClass
{
    [DataMember]
    public String Foo { get; set; }
}

// Your class, used for internal processing
class MyWCFDataClass : WCFDataClass
{
    public String MyFoo { get; set; }

    public String DoFoo()
    {
        return this.Foo + this.MyFoo;
    }
}

Answer 2

Если вы заинтересованы в совместимости, я не верю, что это хорошая практика.

Сначала создается договор (договор на эксплуатацию, договор на сообщение, договор на передачу данных и т. Д.), Чтобы однозначно указать, что поддерживается, а что нет. Это явно определяет эти вещи публично. Это очень сбивает с толку, очень быстро, когда вы начинаете объявлять частных членов частью публичного контракта. Программисту, который приходит за вами, становится проблематично понять, что происходит.

Вы, вероятно, пытаетесь включить логику в свои контракты на данные, что не является целью контракта на данные. Как предлагает @CodeCaster, такие манипуляции должны выполняться вне класса контракта данных. Даже простые вещи, такие как конструкторы, заполняющие значения по умолчанию, могут быть проблематичными. Такая логика также должна выполняться вне класса DataContract.

Кроме того, когда вы объявляете закрытыми членами [DataMember] s, вы полагаетесь на нестандартные подробности реализации сериализатора контракта данных - тот факт, что он может читать / записывать элементы, которые не являются публичными - то есть DataConstractSerializer (по крайней мере, на платформе .NET) может делать то, что вы не могли делать в своем собственном коде. Вы зависите от «магии». Хотя это «волшебство» помогает DataConstractSerializer обеспечивать удивительную производительность, я не думаю, что вам следует полагаться на детали его реализации. Например, вы обнаружите, что такие классы DataContract нельзя использовать совместно с приложениями Silverlight, поскольку на этой платформе DataConstractSerializer не может читать / писать непубличные элементы.

Однако, как и все «практики», вы должны учитывать ваши обстоятельства. Если совместимость и ремонтопригодность не являются обязательными, то большинство из вышеперечисленного не имеет значения и может быть проигнорировано. :)