Зачем использовать сериализации

Question

Я видел пару примеров с сериализуемым атрибутом, как это:

[Serializable()] 
      public class sampleClass 
      { 
       public int Property1{ get; set; } 
       public string Proerty2{ get; set; } 

       public sampleClass() { } 
       public sampleClass(int pr1, int pr2) 
       { 
        pr1 = pr1; 
        Name = pr2.ToString(); 
       } 
      } 

Я никогда не имели хорошее представление о понимании того, как это работает, но из msdn:

сериализации позволяет разработчику сохранять состояние объекта и воссоздавать его по мере необходимости, обеспечивая хранение объектов, а также обмен данными . Через сериализацию разработчик может выполнять действия как отправку объекта в удаленное приложение с помощью веб-сервиса , передавая объект из одного домена в другой, передавая объект через брандмауэр в виде строки XML или поддерживая безопасность или пользовательская информация в приложениях.

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

Обновление: Спасибо за все хорошие ответы

Answer 1

Сериализации полезно в любое время вы хотите переместить представление данных в или из вашей границы процесса.

Сохранение объекта на диске - тривиальный пример, который вы увидите во многих учебниках.

Как правило, сериализация используется для передачи данных в веб-службу или из нее или для сохранения данных в базе данных или из нее.

Answer 2

Приведенная вами ссылка MSDN объясняет, когда сериализация полезна: для транспортировки или хранения данных. Запись в файл - это сериализация, и требуется сериализация. T отправка объекта по сети.

Если вы просто заселяете объект в одном приложении, возможно, из базы данных, то действительно: сериализация не является проблемой. Отображение класса для сериализации не влияет на безопасность или производительность: если вам это не нужно, не беспокойтесь об этом.

Следует также отметить, что [Serializable] в основном относится к BinaryFormatter, но на самом деле существует гораздо больше сериализаторов, чем это. Например: вы можете открыть свой объект через JSON или XML - обе из них требуют сериализации, но ни один из них не требует [Serializable].

Answer 3

Простой пример: представьте, что у вас есть пользовательская форма для хранения настроек приложения.

namespace My.Namespace 
{ 
    [Serializable] 
    public class Settings 
    { 
     public string Setting1 { get; set; } 

     public string Setting2 { get; set; } 
    } 
} 

Вы могли бы иметь файл файл XML, как например:

<?xml version="1.0" encoding="utf-8" ?> 
<Settings> 
    <Setting1>Foo</Setting1> 
    <Setting2>Bar</Setting2> 
</Settings> 

Использование XmlSerializer вы можете просто сериализации и десериализации параметры.

Также необходимо, чтобы ваша форма была Serializable, если вы хотите наполнить ее в ASP.NET ViewState

Это очень простые примеры, но продемонстрировать это полезность

Answer 4

Несколько ответов рассмотрели причины, почему вы можете захотеть использовать сериализацию в целом. Вы, похоже, также хотите знать, почему у определенного класса есть атрибут [Serializable], и вам интересно, почему это могло быть сделано.

С ASP.NET хранилище состояний по умолчанию - InProc, которое позволяет хранить любой объект в качестве ссылки и оставить его в куче. Это наиболее эффективный способ хранения состояния сеанса, однако он работает только в том случае, если вы используете один рабочий поток или если все состояние сеанса может быть автоматически восстановлено, если рабочий поток должен измениться (маловероятно). Для других режимов хранения состояния (StateServer и SQL Server) все объекты состояния сеанса должны быть сериализуемыми, поскольку механизм ASP.NET сначала сериализует эти объекты с помощью двоичной сериализации перед отправкой их на носитель данных.

В вашем случае вы можете использовать InProc. Одна из причин состоит в том, чтобы по-прежнему отмечать все классы, которые используются в состоянии сеанса как Serializable, и протестировать их таким образом, что вам может понадобиться изменить это в будущем (например, для использования веб-фермы). Если вы не разрабатываете свои классы состояния сеанса с учетом этого, будет довольно сложно выполнить миграцию в будущем.

Кроме того, только потому, что вы можете удалить атрибут Serializable, и программа «работает» в одной среде не означает, что она будет работать в другой среде. Например, это может сработать для вас в тестовом веб-сервере Visual Studio (который всегда использует экземпляр состояния сеанса InProc) и даже в экземпляре IIS разработки, но затем, возможно, для экземпляра IIS для производства используется другой режим хранения.

Эти различия в окружающей среде/конфигурации не обязательно ограничиваются приложениями ASP.NET. Существуют и другие механизмы приложений, которые могут выполнять это или даже автономные приложения (нетрудно построить такую ​​конфигурационную среду).

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

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

Вы спрашивали, будет ли использование [Serializable] медленнее. Нет, этого не будет. Этот атрибут не влияет на производительность. Однако, если среда приложения изменена для сериализации объекта, тогда да, производительность будет затронута. Это процесс сериализации и десериализации, который медленнее, чем просто хранение объекта в куче. [Обратите внимание, что некоторые подпрограммы могут быть записаны для поиска атрибута Serializable, а затем выберите сериализацию, но это редко; обычно это похоже на ASP.NET и оставляется администратору или пользователю, чтобы решить, хотите ли они изменить среду хранения.]

Answer 5

Каковы другие способы использования и когда не использовать сериализацию.

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

Я использовал Xsd2Code для генерации C# классов на основе схемы. Таким образом, разбор запроса XML - это просто десериализация его созданного объекта класса запроса. Тогда я могу получить доступ к свойствам объекта так, как он появляется в запросе XML. При генерации ответа XML файл просто сериализует из сгенерированного объекта класса ответа, который я заполняю в своем коде. Таким образом, я могу работать с объектами C#, а не с XML файлами. Надеюсь, это имеет смысл.

Например, я должен всегда использовать serializzation, потому что это более безопасным

Я не думаю, что это связано с безопасностью в любом случае.