Разница в использовании атрибутов / интерфейсов в C # - PullRequest
3 голосов
/ 22 июля 2010

Это не совсем вопрос, а нечто вроде мысли, которая у меня была недавно.Я использую XmlAttribute для XmlSerialize класса в качестве примера: вы можете установить атрибуты для класса, чтобы выбрать, какие свойства следует сериализовать, но то же самое можно сделать довольно легко, реализовав теоретический интерфейс IXmlSerializable (он действительно существует что-то подобное,Я не помню) и перегружая метод "Serialize" для этого класса, который просто вызывает Serialize для свойств, которые вы хотите сериализовать (this.myProp1.Serialize ()), то же самое для Deserialize

Так что яЯ в основном говорю: не является ли метод Attribute немного избыточным?(Мне это действительно нравится, но я не нахожу это логически отличным от интерфейса)

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

Обновление 1: Ну, я неправильно объяснил себе, что я спрашиваю: «Почему я должен выбрать атрибут вместо интерфейса (или наоборот)», а не именно этот конкретный случай(Я взял сериализацию, потому что это было первое, что всплыло в моей памяти), кстати, спасибо за ваш ответ, потому что они очень интересны

Ответы [ 4 ]

8 голосов
/ 22 июля 2010

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


"довольно просто"?ХОРОШО;Я довольно опыт в сериализации, но реализация для этого - , а не , что я называю легким.Напротив, на самом деле.

Если вы не хотите использовать атрибуты, существует перегрузка для XmlSerializer, которая позволяет настраивать его во время выполнения.

Но я содрогаюсь всякий раз, когдаЯ слышу "реализовать IXmlSerializable".Атрибутивный подход очень быстрый и простой:

[XmlRoot("foo"), XmlType("foo")]
[XmlInclude(typeof(SuperFoo))]
public class Foo {
    public string X {get;set;}

    [XmlAttribute("y")]
    public int? Y {get;set;}

    [XmlElement("item")]
    public List<string> Items {get;set;}
}
public class SuperFoo : Foo {}

Я призываю вас написать надежную реализацию IXmlSerializable для этого очень простого примера ниже 2часов ... и помните, что каждая написанная вами строка - это строка, которую вы должны поддерживать.

4 голосов
/ 22 июля 2010

Ну, насколько я могу судить, они логически разные.

Реализация IXmlSerializable напрямую влияет на сам класс, потому что вы добавляете интерфейс и один или несколько методов в реализацию класса. По сути, вы создаете свой собственный класс напрямую и ответственно за его сериализацию.

Однако добавление атрибутов XmlAttribute напрямую не влияет на функциональность класса, вместо этого вы просто украшаете его атрибутами, чтобы XmlSerializer мог выполнять фактическую функцию сериализации. В этом случае вы откладываете сериализацию до класса XmlSerializer и предоставляете достаточно метаданных о вашем классе, чтобы XmlSerializer мог выполнить свою работу.

Вот почему я предпочитаю последний атрибутный подход. Когда я пишу класс, я хочу, чтобы он был сериализуемым, но последнее, что меня волнует, это специфика реализации, поэтому я всегда начинаю с подходом thaqt, и в 99% случаев он работает нормально при минимальной работе. Однако, если вам нужно более детальное управление сериализацией, внедрите интерфейс IXmlSerializable и напишите свой собственный код сериализации.

1 голос
/ 22 июля 2010

Вы можете выбрать свойства для (не) сериализации с атрибутами. Реализация интерфейса - сериализация по коду.

1 голос
/ 22 июля 2010

Программный метод реализации интерфейса может дать немного больше контроля (и, вероятно, большую скорость), но его сложнее создать и поддерживать, чем метод атрибута.Я в основном использую атрибуты.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...