How to represent an object and map between different sources/locations

I will be building a system where a particular object will originate from a web service (SOAP based). It will then be displayed on a web page (via PHP). Under certain circumstances we'll store a copy with some additional information in a local MySQL database. And from there it will be batch processed into Salesforce CRM (again via PHP). We may also subsequently pull the object out of Salesforce for display online. So alot going on. For the most part the object is the same with each subsequent node in the system likely adding a couple of fields specific to it, unique ids mainly.

I'd initially toyed with the idea of encapsulating all the necessary functionality into the one class in PHP which would deal with reading and writing from each of the appropriate sources. This felt like it was over complicating the class, and not a good approach.

I then looked at having just a container class, with no real functionality attached beyond getters and setters. Then creating separate functionality outside of this to deal with the reading and writing between the different sources, simple enough code although tedious to map between all the different field names across the different sources. There is probably a design pattern or two that apply here, but I'm开发者_Python百科 not familiar with them. Any and all suggestions on how to approach this appreciated.

What you are looking is Adapter pattern. You can keep your existing code till you completely change all the classes.

I'd suggest to use a composite memento serializable into XML.

I think they may be several ways to handle that. @EGL 2-101 adapter idea is one way to do it.

Basically, you have several sources, which in O.O. jargon, are different objects. But, you want to treated like if they where a single object.

You may want to make a single class for each source, test the "connection", as if each case was the only way you where going to work with. When you have several of that classes, try to make all classes share some interface, methods or properties:

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

Later, use a single class to wrap to all of these source classes.

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

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

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

} // class

Later, add the code, to select which "connection" you want.

Why not separate data and operations?

Contain the core information into a class C. When web services sends this class, it is encompassed in an object of some class W. The web service pulls C and sends it to persistence layer, which creates and stores P that internally contains C, et.c.,
Akin to how data flows over a TCP/IP stack...

The way I see this after thinking about it a bit would be pretty much a class to play with your object and then serialize it. I'd probably use something like this:

<?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();
    }
}

Then just use it to pass it serialized to your different web services. I think JSON would do a pretty good job on this one, because you can easily unserialize it fast in so many programming languages and it's so much lighter than XML.

DataMapper pattern is that what you're looking for.

You can have one mapper for each storage mechanism that you use and use them all with one object that represent data to business logic.

Is seems your problem is more of an architectural / design decision that pure implementation detail. (I haven't done PHP for a long while and do not know salesforce but other CRM systems)

I believe the technique/pattern that will work for you is the use of a staging area. This helps especially if you have changing integration needs and also when your source data looks different from your system model or when you have different sources to integrate from. Thus, you import into the staging area and then from the staging into your system. At each place you naturally have to map (can use metadata) and maybe transform/translate data. There will be initial effort to build this, but once it's done the step from staging to your system stays quite static/stable.

Using meta data mapping can address flexibility concerns but adds a bit of complexity on implementation. It all depends on the skills and time you have at hand for your project.

I would not have any association between the objects at all. They are used for different purposes but looks similar. period.

In .NET we use a library called automapper to copy information between different classes (like a business object and a DTO). You can build something similar in PHP, either by using get_object_vars or the reflection API.

myCopyApi.copy($myDTO, $myBO);

Say you retrieve a Car from the webservice. You can store it in a WebserviceCar, which has a property car.

Now, if you want to store that Car in the database, put it in a DatabaseCar, which also has a property car. If you want to put it in Salesforce, put it in a SalesforceCar object, which has a property car.

This way, you have one object which has the common fields and several objects which have storage-specific information.

Assuming that you are thinking about storing the actual object (serialized,encoded or whatever) in a field in the database: From my point of view the object it is never the same in two applications, as business-wise, it serves different purposes. Doing this is a kind of "cutting short" in a case where is no room for "cutting short". Remember that mainly class represents a "category of objects" which all share same properties and behaviours. So let each application use it's own class as their purpose requires it. What can be created although is, as others suggested and as you thought, the creation of an Adapter or Factory which can be used in all the implied applications as it serves the same business purposes "translation" of objects.

Adapter pattern

Factory pattern