Способ сериализации объектов с сервера приложений на веб-сервер без дублирования кода

Question

У меня есть трехуровневая настройка сервера web-app-database. Веб запрашивает данные из приложения, и приложение получает свои данные из базы данных, затем обрабатывает и возвращает их в Интернет для отображения. Стандарт.

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

Теперь я изучаю сериализацию всего объекта заказа на веб-сервере.

Какой метод, который вы, ребята, нашли, лучше всего сериализовать при сохранении разделения кода сервера приложений и веб-сервера? Я не хочу, чтобы у моих веб-серверов был какой-либо код, который обращается к БД, но я хочу, чтобы они максимально использовали классы, которые инкапсулируют мой заказ и другие данные.

Чтобы еще больше уточнить мой вопрос (благодаря ответу Гленна), я не хочу, чтобы у моих веб-серверов была какая-либо бизнес-логика, скажем, также класс заказов, который должен знать только сервер приложений. Объекты уже используют отдельную сериализацию в / из базы данных и в / из веб-серверов.

Используя пример заказа на сервере приложений, заказ должен быть в состоянии отменить: т.е.

$ заказа запасного> отменить ();

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

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

Веб-серверы и серверы приложений могут независимо расширять базовый класс и использовать собственный внутренний класс для хранения свойств. Тогда, например, на стороне приложения внутренний класс может быть расширением класса ORM, который может сохранять данные в БД, а на веб-стороне внутренний класс может быть простым классом-держателем свойств.

Но весь внутренний класс кажется немного неуклюжим, поэтому я все еще ищу лучшие решения.

Answer 1

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

Answer 2

Если я правильно понимаю ваш вопрос, вы хотите сериализовать данные ваших объектов, но когда они будут повторно гидратированы, они должны превратиться в объект другого типа (с ограниченной и / или другой функциональностью)?

Вы можете сделать это по-разному, в зависимости от того, какой протокол вы предпочитаете. Например, вы можете использовать SOAP. Затем вы должны объединить объекты в другой класс на стороне клиента, чем на стороне сервера. Вы также можете использовать нативную сериализацию PHP и либо: а) иметь другую клиентскую базу кода (может привести к путанице), либо б) немного поиграться с сериализованной строкой (например, заменить имя класса) , Грубый пример можно найти в комментариях к руководству по PHP.