Почему объекты transfer должны реализовывать Serializable?

Question

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

Мне сказали, что это из-за репликации сеанса между серверами с балансировкой нагрузки, но я знаю, что видел другие объекты в области сеанса, которые не реализуют Serializable .Это настоящая причина?

Answer 1

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

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

Answer 2

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

Например, двоичный файл, или xml, Json, или аналогичный

Здесь есть больше информации... Должен ли какой-либо объект домена не быть сериализуемым?

Answer 3

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

Я помню, как использовал Sun RPC (в настоящее время называемый ONC RPC), который выполняет кодирование XDR потому что компьютерные платформы / системы представляют свои данные в соответствующих формах.Например, большой порядковый номер против малого порядкового номера.

Но JVM, независимо от машины, имеет формат big-endian, поэтому порядковый номер не должен быть причиной.

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

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

Весь наш уровень представления данных в сетях основан на потоке битов.Поэтому, когда вы хотите передать данные из одной системы в другую, вы должны преобразовать размерные данные, представленные в памяти, в те, которые могут передаваться потоком по сетям побайтно.На самом деле, понемногу, и это часто проходит через сжатие и безопасное шифрование.Процедуры сжатия и шифрования не зависят от oo-структуры, и предполагается, что используются битовые потоки.Сетевые коммутаторы не зависят от oo-структуры.Сетевая передача даже не видит битов.Биты кодируются в сигнал передачи, который часто представляет собой аналоговые синусоиды, а затем модулируются.Эти процессы не работают с многомерными / иерархическими схемами оо-структурированных данных.

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

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