Dlaczego użycie serializacji

Question

Widziałem kilka przykładów z atrybutem serializable tak:

[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(); 
       } 
      } 

nigdy nie miałem dobry chwyt na zrozumienie, jak to działa, ale z msdn:

serializacji umożliwia deweloperowi zapisanie stanu obiektu i odtworzenie go w razie potrzeby, zapewniając przechowywanie obiektów oraz wymianę danych w postaci . Poprzez serializację programista może wykonywać akcje, takie jak wysyłanie obiektu do aplikacji zdalnej za pomocą usługi Web , przekazywanie obiektu z jednej domeny do drugiej, przekazywanie obiektu przez zaporę ogniową jako ciąg znaków XML lub utrzymywanie bezpieczeństwa lub specyficzne dla użytkownika informacje w różnych aplikacjach.

Ale problem polega na tym, że w moim przykładzie kodu nie widzę sensu. Tylko obiekt, który służy do pobierania danych z bazy danych, nic specjalnego. Jakie są inne zastosowania, kiedy używać i kiedy nie używać serializacji. Na przykład, czy zawsze powinienem używać serializzacji, ponieważ jest bardziej bezpieczny? czy w ten sposób będzie wolniej?

Aktualizacja: Dzięki za wszystkie miłe odpowiedzi

Answer 1

serializacji jest przydatna za każdym razem chcesz przenieść reprezentację danych do lub z Twojego granicy technologicznej.

Zapisywanie obiektu na dysku to trywialny przykład, który można zobaczyć w wielu samouczkach.

Częściej, serializacja służy do przesyłania danych do iz usługi internetowej lub do utrzymywania danych do lub z bazy danych.

Answer 2

Podany numer MSDN wyjaśnia, kiedy serializacja jest przydatna: do transportu lub przechowywania danych. Zapisywanie do pliku jest serializacją i wymagana jest serializacja t wysyłanie obiektu przez sieć.

Jeśli właśnie wypełniasz obiekt w pojedynczej aplikacji, być może z bazy danych, to naprawdę: serializacja nie jest w ogóle problemem. Obrazowanie klasy do serializacji nie ma wpływu na bezpieczeństwo ani wydajność: jeśli go nie potrzebujesz, nie martw się o to.

Należy również zauważyć, że [Serializable] dotyczy głównie BinaryFormatter, ale w rzeczywistości jest o wiele więcej serializerów. Na przykład: możesz odsłonić obiekt za pomocą JSON lub XML - oba wymagają serializacji, ale nie wymagają one [Serializable].

Answer 3

Prosty przykład: Wyobraź sobie, że masz niestandardowy kształt do przechowywania ustawień aplikacji.

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

     public string Setting2 { get; set; } 
    } 
} 

Można wtedy mieć złożyć pliku xml jako takie:

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

Korzystanie XmlSerializer można po prostu serializacji i deserializacji ustawienia.

Konieczne jest również, aby Twój kształt był Serializowalny, jeśli chcesz umieścić go w ASP.NET ViewState

Są to bardzo podstawowe przykłady, ale pokazują, że to przydatność

Answer 4

Kilka odpowiedzi objęły powody, dlaczego warto używać serializacji w ogóle. Wydaje się, że chcesz również wiedzieć, dlaczego konkretna klasa ma atrybut [Serializable] i zastanawiasz się, dlaczego tak się stało.

W środowisku ASP.NET domyślnym magazynem stanu sesji jest InProc, który umożliwia przechowywanie dowolnego obiektu jako odniesienia i pozostawienie go na stercie. Jest to najlepiej działający sposób przechowywania stanu sesji, jednak działa on tylko wtedy, gdy używasz pojedynczego wątku roboczego lub jeśli cały stan sesji może zostać odbudowany automatycznie, jeśli wątek roboczy zmienił się (mało prawdopodobne). Dla innych stanów przechowywania stanów (StateServer i SQL Server) wszystkie obiekty stanu sesji muszą być przekształcalne do postaci szeregowej, ponieważ silnik ASP.NET najpierw serializuje te obiekty przy użyciu serializacji binarnej przed wysłaniem ich na nośnik pamięci.

W twoim przypadku możesz używać InProc. Jedną z przyczyn jest nadal oznaczanie wszystkich klas używanych w stanie sesji jako Serializable i przetestowanie ich w ten sposób, że może zajść potrzeba zmiany tego w przyszłości (na przykład w celu użycia farmy sieci Web). Jeśli nie zaprojektujesz swoich klas stanu sesji, mając na uwadze powyższe, będzie dość trudno przeprowadzić migrację w przyszłości.

Również dlatego, że można usunąć atrybut Serializable, a program "działa" w jednym środowisku, nie oznacza, że ​​będzie działał w innym środowisku. Na przykład może działać dobrze w przypadku serwera WWW testowego programu Visual Studio (który zawsze korzysta z instancji trybu sesji w stanie InProc), a nawet w instancji programistycznej IIS, ale wtedy prawdopodobnie produkcja IIS instancji jest skonfigurowana do używania innego trybu przechowywania.

Te różnice w środowisku/konfiguracji niekoniecznie są ograniczone do aplikacji ASP.NET. Są inne silniki aplikacji, które mogą to zrobić lub nawet samodzielne aplikacje, które robią (nie jest trudno zbudować tego rodzaju konfigurowalne środowisko).

Wreszcie, możesz pracować z biblioteką, która może być używana przez różne aplikacje. Niektóre z nich mogą wymagać przechowywania stanu w sposób umożliwiający szeregowanie, a inne nie.

Ze względu na te czynniki często jest to bardzo dobry pomysł, przynajmniej podczas budowania biblioteki, do rozważenia oznaczania prostych klas wartości lub klas zarządzania stanami z [Serializable]. Należy pamiętać, że zwiększa to wydajność testowania tych klas i istnieją ograniczenia co do serializacji (np. Klasa zawierająca odwołanie do gniazda lub odwołanie do otwartego pliku może nie być dobrym kandydatem do serializacji, ponieważ otwarte zasoby zewnętrzne nie mogą być serializowane) więc nie nadużywaj tego.

Zapytałeś, czy użycie [Serializable] będzie wolniejsze. Nie, nie będzie. Ten atrybut nie ma bezpośredniego wpływu na wydajność. Jeśli jednak środowisko aplikacji zostanie zmienione, aby serializować obiekt, wówczas tak, wpłynie to na wydajność. To jest serializowanie i deserializacja, która jest wolniejsza niż tylko przechowywanie obiektu na stercie. [Należy zauważyć, że niektóre procedury mogą być zapisane w celu wyszukania atrybutu Serializable, a następnie wyboru serializacji, ale jest to rzadkie; zazwyczaj jest to podobne do ASP.NET i pozostawione administratorowi lub użytkownikowi, aby zdecydować, czy chcą zmienić nośnik pamięci.]

Answer 5

Jakie są inne zastosowania dotyczące używania i kiedy nie korzystać z serializacji.

Pozwolę sobie podać jeden praktyczny przykład.W jednym z moich zgłoszeń otrzymałem schematy XML (pliki XSD) dla plików żądania i odpowiedzi XML. Muszę przeanalizować plik żądania, przetwarzać i zapisywać informacje z powrotem w kilku tabelach. Później muszę odpowiednio przygotować plik odpowiedzi i wysłać go do naszego klienta.

Do generowania klas C# używano klas opartych na schemacie. Przetwarzanie pliku XML wymaga po prostu przekształcenia w wygenerowany obiekt klasy żądania. Wtedy mogę uzyskać dostęp do właściwości z obiektu w sposób, w jaki pojawia się w pliku żądania XML. Podczas generowania odpowiedzi plik XML jest po prostu serializowanie z wygenerowanego obiektu klasy odpowiedzi, który zapełniłem w moim kodzie. W ten sposób mogę pracować z obiektami C#, a nie XML. Mam nadzieję, że to ma sens.

Na przykład, należy zawsze używać serializzation ponieważ jest bardziej bezpieczne

Nie sądzę, jest to związane z bezpieczeństwem w jakikolwiek sposób.