Jump to content

design a system to integrate with 3rd parties


CaptainChainsaw

Recommended Posts

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 :)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.