design a system to integrate with 3rd parties

[CaptainChainsaw]

Hi all,

 

I'm looking to design a OO system that interacts with 3rd parties who use SOAP, GET AND POST. These 3rd parties each have their own way of more or less doing the same thing.

 

For example. Say I want to pass them a credit card name, one 3rd party may expect "Mastercard" and another might expect "MSC" to be passed.

 

At the moment I'm thinking I could, for example have a set method like so:

 

$card->setMastercard("MASTERCARD");

 

Another method to find the correct mapping for it:

 

$card->findMapped();

 

This may mean a scaleabilty problem if a new card is added in the future.

 

I could create a method is some subclass that takes these details as params, perhaps something like:

 

$thirdParty->('$URL_TO_POST_TO', 'SOAP'
,array('
"MSC" => "MASTERCARD,
"VIS" => "VISA"
'),
// etc
);

 

This would make it potentially a nightmare if a lot of params need passed in but would mean if another card was added, the code wouldn't need changed and it would just mean adding another element in the array.

 

Anyone got any tips or suggestions on how best to tackle this? I'm thinking GET/POST/SOAP parent classes and a "3rd party" subclass. These are just rough ideas.

 

 

Thanks in advance,

 

CaptainChainsaw

[Psycho]

Why would you hard code these values rather than putting them into a database which would be infinitely easier to maintain and manage? You can then define the different cards and the "names" that each third party product uses.

Edited February 5, 2013 by Psycho

[CaptainChainsaw]

That might be an option but performance is high priority and another db hit might have an effect on that. These card types and other details currently aren't stored on the DB they're simply values on a form, adding the details to a DB and not updating the form dynamically using db values would mean changes in two places.

[Psycho]

You should not be hard-coding data that is variable. If you design your database and logic appropriately the performance should be minimal. You would only need one or two tables. To be truly normalized you would want two tables: one for the card types and an associative table for the vendor names of each card type. But, if performance is a problem and you do not foresee having to add many vendors over time you could have one table with a record for each card type and a column for each vendor. To add a new vendor you would only need to add a column and enter the value that the vendor uses for each card. You would doing a query against a table that only contains a dozen or so records.

Edited February 5, 2013 by Psycho