Serializacja służy do trwałości w Javie. Zachowanie kilku obiektów przy użyciu serializacji może być w porządku. Ale w przypadku dużej liczby obiektów lepsza może być ORM, baza danych itp. Wydaje się, że serializacja jest przydatna tylko w przypadku małych prac. Może się mylę. Więc proszę powiedz mi, jakie są zalety serializacji w porównaniu z metodami nie serializacji? Kiedy należy go używać, a kiedy należy tego unikać?
To pytanie przyszło mi do głowy po przeczytaniu artykułu DZone Is Object Serialization Evil?
A oto linie, które zrodziły moje pytanie:
Jeśli spojrzysz na Javę i jej obiekty sesji, używana jest serializacja czystych obiektów. Zakładając, że sesja aplikacji jest dość krótkotrwała, co oznacza najwyżej kilka godzin, serializacja obiektów jest prosta, dobrze obsługiwana i wbudowana w koncepcję sesji Java. Jednak gdy trwałość danych trwa dłużej, być może dni lub tygodnie, i musisz martwić się nowymi wersjami aplikacji, serializacja szybko staje się zła. Jak każdy dobry programista Java wie, jeśli planujesz serializować obiekt, nawet w sesji, potrzebujesz prawdziwego identyfikatora serializacji (serialVersionUID), a nie tylko 1L i musisz zaimplementować interfejs Serializable. Jednak większość programistów nie zna prawdziwych reguł procesu deserializacji Java. Jeśli Twój obiekt się zmienił, to nie tylko dodawanie prostych pól do obiektu, możliwe jest, że Java nie może poprawnie przekształcić obiektu z postaci szeregowej, nawet jeśli identyfikator serializacji nie zmienił się. Nagle nie możesz odzyskać swoich danych, co jest z natury złe.
Teraz programiści czytający to mogą powiedzieć, że nigdy nie napisaliby kodu, który miałby ten problem. To może być prawda, ale co z biblioteką, której używasz lub innym programistą, który nie jest już zatrudniony w Twojej firmie? Czy możesz zagwarantować, że ten problem nigdy się nie wydarzy? Jedynym sposobem na zagwarantowanie tego jest użycie innej metody serializacji.
1L” jest nieprawidłowa.