Как представить объект и карту между различными источниками / местоположениями

Question

Я буду строить систему, в которой конкретный объект будет происходить из веб-службы (на основе SOAP). Затем он будет отображаться на веб-странице (через PHP). При определенных обстоятельствах мы будем хранить копию с некоторой дополнительной информацией в локальной базе данных MySQL. Оттуда он будет пакетно обработан в Salesforce CRM (снова через PHP). Мы также можем впоследствии извлечь объект из Salesforce для отображения в Интернете. Так много происходит. По большей части объект одинаков с каждым последующим узлом в системе, который, вероятно, добавляет пару специфических для него полей, в основном уникальные идентификаторы.

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

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

Answer 1

То, что вы ищете: Адаптер шаблон.Вы можете сохранить существующий код до полного изменения всех классов.

Answer 2

Я бы предложил использовать составной сувенир , сериализуемый в XML.

Answer 3

Предполагая, что вы думаете о сохранении фактического объекта (сериализованного, закодированного или чего-либо еще) в поле в базе данных: с моей точки зрения, объект никогда не бывает одинаковым в двух приложениях, так как в бизнесе он служитразные цели.Выполнение этого является своего рода «коротким замыканием» в случае, когда нет места для «короткого замыкания».Помните, что в основном класс представляет собой «категорию объектов», которые имеют одинаковые свойства и поведение.Поэтому пусть каждое приложение использует свой собственный класс, как того требует их назначение.Что может быть создано, хотя, как другие предложили и как вы думали, это создание Адаптера или Фабрики, которые можно использовать во всех подразумеваемых приложениях, поскольку они служат для тех же целей бизнеса «перевод» объектов.

Шаблон адаптера

Заводской шаблон

Answer 4

Скажем, вы получаете автомобиль из веб-службы. Вы можете сохранить его в WebserviceCar, у которого есть автомобиль.

Теперь, если вы хотите сохранить этот Автомобиль в базе данных, поместите его в DatabaseCar, в котором также есть автомобиль. Если вы хотите поместить его в Salesforce, поместите его в объект SalesforceCar, у которого есть свойство car.

Таким образом, у вас есть один объект с общими полями и несколько объектов с информацией о хранилище.

Answer 5

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

В .NET мы используем библиотеку с именем automapper для копирования информации между различными классами (например, бизнес-объект и DTO). Вы можете создать нечто подобное в PHP, используя get_object_vars или отражающий API.

myCopyApi.copy($myDTO, $myBO);

Answer 6

Кажется, ваша проблема - это скорее архитектурно-дизайнерское решение, а не детали реализации. (Я давно не занимался PHP и не знаю Salesforce, но других систем CRM)

Я считаю, что техника / шаблон, который будет работать для вас, - это использование области подготовки . Это особенно полезно, если у вас есть изменяющиеся потребности в интеграции, а также когда ваши исходные данные выглядят не так, как ваша модель системы, или когда у вас есть другие источники для интеграции. Таким образом, вы импортируете в промежуточную область, а затем из промежуточной в свою систему. В каждом месте вы, естественно, должны отображать (можете использовать метаданные) и, возможно, преобразовывать / переводить данные. Первоначальные усилия будут предприняты для его создания, но после того, как он будет сделан, переход от установки к вашей системе остается довольно статичным / стабильным.

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

Answer 7

DataMapper - это то, что вы ищете.

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

Answer 8

Я думаю, у них может быть несколько способов справиться с этим.Идея адаптера @EGL 2-101 - это один из способов сделать это.

По сути, у вас есть несколько источников , которые в жаргоне OO - разные объекты.Но вы хотите, чтобы относились, как если бы они были одним объектом.

Вы можете создать отдельный класс для каждого источника, проверить «соединение», как если бы каждый случай был единственным способом, с которым вы собираетесь работать.Если у вас есть несколько таких классов, попытайтесь заставить все классы совместно использовать некоторые интерфейсы, методы или свойства:

class AnyConnection 
{
    public function __construct() {
        // ...
    }

    public function read() {
        // ...
    }

} // class


class SOAPObject extends AnyConnection
{
    public function __construct() {
        // ...
    }

    public function read() {
        // ...
    }

} // class

class MYSQLObject extends AnyConnection
{
    public function __construct() {
        // ...
    }

    public function read() {
        // ...
    }

} // class

class SalesObject extends AnyConnection
{
    public function __construct() {
        // ...
    }

    public function read() {
        // ...
    }

} // class

Позже используйте один класс для переноса на все эти исходные классы.

class AnyObject extends AnyConnection
{
    $mySOAPObject;
    $myMYSQLObject;
    $mySalesObject;

    public function __construct() {
        // ...
    }

    public function read() {
        // ...
    }

} // class

Позже добавьте код, чтобы выбрать, какое «соединение» вы хотите.

Answer 9

То, как я это вижу, немного подумав, было бы классом для игры с вашим объектом, а затем сериализации. Я бы, наверное, использовал что-то вроде этого:

<?php

class MyObject
{
    protected $_data;

    public function __construct($serializedObject = null) {
        if(!is_null($serializedObject)) {
            $this->_data = json_decode($serializedObject);
        }
    }

    public function __get($key) {
        return $this->_data[$key];
    }
    /* setter and other things you need */

    public function encode() {
        return json_encode($this->_data);
    }    

    public function __toString() {
        return $this->encode();
    }
}

Тогда просто используйте его, чтобы передать его сериализованным вашим различным веб-сервисам. Я думаю, что JSON отлично с этим справится, потому что вы легко можете легко его не сериализовать во многих языках программирования, и он намного легче XML.

Answer 10

Почему бы не разделить данные и операции?

Содержит основную информацию в классе C.Когда веб-сервисы отправляют этот класс, он включается в объект некоторого класса W.Веб-служба извлекает C и отправляет его на уровень персистентности, который создает и хранит P, который внутренне содержит C, et.c.,
Аналогично тому, как данные передаются через стек TCP / IP ...