views:

75

answers:

3

So,

I currently am working on a project, in which two different datasources will be updated.

The business objects have similar structures, but not exactly the same.

What I have currently planned on doing, is using a provider interface, so I have have a handler class to push to both databases.

As the 2nd object is from an external API, I thought that the best thing to do, is push my custom object through, and in the API's provider, to map things over manually, so the other developer implementing the forms etc for this would be able to do all this seemlessly.

I suppose I am always going to have to do the mapping over at some point, but I was wondering if anyone had a nicer way that just doing it in the implemented methods - below is skeleton on what I was currently thinking.. any ideas?

IBusinessObject1PushProvider
{
   Create();
}


DSOneBusinessObject1Pusher : IBusinessObject1PushProvider
{
   Create()
   {
       // move custom object into our database
   }
}

DSTwoBusinessObject1Pusher : IBusinessObject1PushProvider
{
   Create()
   {
       APIObj1 ob1 = new APIObj1();
       ob1.Name = obPassedThrough.FirstName + obPassedThrough.LastName;

       // move ob1 to the webservice having had the datamassaged.
   }
}
+1  A: 

Well my idea when implementing such feature would be:

  1. Assume that a one-on-one mapping is normal behaviour
  2. Specify exceptions to rule 1

So basically, copy properties from your custom object to the api object, as long as the fieldNames and types match (you can do some specification on this with attributes or something); you can use reflection and dynamic expressions to do this fast and reliable.

To specify exceptions to the first rule, (such as ob1.Name = obPassedThrough.FirstName + obPassedThrough.LastName; in your example) you have to specify the wanted behaviour. You can do this either in code using some generic convertion pattern, or specify this in XML or something.

This way you should be able to create quite straightforward code to post all kinds of objects to either your own database and 3rd parties. Normal objects who are the same on both sides immediately work, and strange behaviour can easily be implemented by a developer.

Jan Jongboom
+1  A: 

The best solution may be to use an adapter pattern.

Define an interface that covers the desired API that is not specific to a certain implementation, then define two adaptors - one for each data-source, that implement the interface - each translating it to the underlying API.

This approach will allow you to replace either of the data-sources without changing anything but the adapter above it.

If you need a short example leave a comment.

Danny Varod
this is kind of closest to what i was expecting for an answer. i think using this or the provider model i had suggested effectively work out to be the same.
tim
A: 

As it is clearly possible for your datastores to get out of sync. it would be a good idea to have some sort of status flag in you local db something like:-

set local_stat = IN_PROGRESS;
id = create(the_data,local_stat);
commit;
send to remote_service();
if (ok) 
then 
    set local_stat = IN_SYNC;
else
    set local_stat = OUT_OF_SYNC;
update(id,local_stat);
commit;

You will then be able to recover from most error conditions.

James Anderson