Метод сериализации объектов с сервера приложений на веб-сервер без дублирования кода
У меня есть установка сервера 3 уровня базы данных веб-приложений. Интернет запрашивает данные из приложения, а приложение получает данные из базы данных, затем обрабатывает и возвращает их в Интернет для отображения. Стандарт.
В настоящее время все данные, которые я сериализую из приложения в Интернет, помещаются в настраиваемые структуры данных, которые затем веб-сторона анализирует для отображения. Другими словами, скажем, у меня есть заказ, который я хочу получить и отправить в Интернет. Я не сериализую весь объект, а скорее создаю массив с соответствующими элементами данных на сервере приложений, а затем сериализую этот массив на веб-серверы.
Теперь я собираюсь сериализовать весь объект заказа на веб-сервер.
Как вы, ребята, нашли лучший метод сериализации объектов при сохранении разделения кода сервера приложений и кода веб-сервера? Я не хочу, чтобы у моих веб-серверов был какой-либо код, который обращается к БД, но я хочу, чтобы они как можно больше повторно использовали классы, которые инкапсулируют мой заказ и другие данные.
Чтобы еще больше уточнить мой вопрос (благодаря ответу Гленна), я не хочу, чтобы на моих веб-серверах была какая-либо бизнес-логика, указывающая также класс заказа, который должен знать только сервер приложений. Объекты уже используют отдельную сериализацию в / из базы данных и на / из веб-серверов.
Используя пример заказа на сервере приложений, заказ должен иметь возможность отмены: т.е.
$ заказ-> отменить ();
но на веб-сервере этот метод даже не должен быть найден. Он не должен просто прокси-сервером (напрямую) к методу отмены заказа сервера приложений, потому что запросы действий пользователя должны проходить через уровень авторизации и проверки разрешений приложения.
Итак, как мне получить объект заказа на моем веб-сервере, который имеет некоторые (но не все) методы и свойства объекта на моем сервере приложений, практически без дублирования кода. Одна вещь, о которой я думал, - это создать базовый класс с ограниченным набором свойств и методов. Он будет использовать внутренний класс для хранения своих свойств, и мне потребуется, чтобы весь доступ к данным проходил через методы получения и установки. Они, в свою очередь, будут вызывать геттеры и сеттеры внутреннего класса.
Затем веб-серверы и серверы приложений могут независимо расширять базовый класс и использовать настраиваемый внутренний класс для хранения свойств. Затем, например, на стороне приложения внутренний класс может быть расширением класса ORM, который может сохранять данные в БД, а на веб-стороне внутренний класс может быть простым классом-держателем свойств.
Но вся эта штука с внутренним классом кажется немного неуклюжей, поэтому я все еще ищу лучшие решения.
Ответы 2
- Вынесение конкретного формата код сериализации в отдельные классы с использованием Адаптер шаблон. Ваша проблемная область классы становятся вспомогательным складом нейтральный.
- Используйте классы адаптера для реляционной базы данных на уровне приложения для сериализации объектов на уровень данных и обратно.
- Используйте специальные классы адаптеров HTML на веб-уровне для сериализации объектов в веб-браузер и из него.
- Используйте XML (или любой другой удобный для проводного протокола формат, который вы считаете наиболее подходящим) определенные классы адаптеров как на веб-уровне, так и на уровне приложений, чтобы сериализовать объекты между веб-уровнем и уровнем приложения.
- Вы получите дополнительные баллы, если достаточно сообразительны, чтобы выяснить, как сделать эти классы адаптеров достаточно универсальными, чтобы вам не требовался другой набор классов адаптеров для каждого класса предметной области.
Если я правильно понимаю ваш вопрос, вы хотите сериализовать данные своих объектов, но когда они повторно гидратируются, они должны быть таковыми в другой тип объекта (с ограниченными и / или другими функциями)?
Вы можете сделать это по-разному, в зависимости от того, какой протокол вы предпочитаете. Например, вы можете использовать SOAP. Затем вы должны преобразовать объекты в другой класс на стороне клиента, чем на стороне сервера. Вы также можете использовать собственный PHP сериализация и либо а) иметь другую базу кода на клиенте (может сбить с толку), либо б) немного поиздеваться над сериализованной строкой (например, заменить имя класса). Грубый пример можно найти в комментариях к руководству по PHP.
да, например, приведите объект порядка сервера приложений к его родительскому классу (назовите его Order_Base), а затем выполните регидратацию на стороне веб-сервера как Order_Base, а затем, возможно, передайте это в конструктор подкласса на стороне веб-сервера, чтобы построить там подкласс. Хотя все это немного неуклюже ...