What typical pattern(s) are used for a system that integrates data from many sources with non standard apis?

I've never asked anything this general before, and I'm not sure if it's going to sound like I'm asking for someone to do my work for me. I'm an experienced programmer but I'm somewhat new to the kinds of design patterns that get talked about on sites like this.

Synopsis of parameters:

(1) There are 3 external systems that are effectively data stores

System1 - REST System2 - WSDL System3 - COM Interop

(2) Data entities are meaningful in 2 of the systems, moving both to and from (the 2 respective systems)

(3) The whole thing is driven by a synchronization manager app.

Synopsis of implementation:

(4) Data entities are defined by interfaces living in a separate namespace.

IFoo IBar IBaz

(5) Work is done by Utility classes that live in a namespace dedicated to the system.

namespace MyCompany.Integrations.System1 {
 public static class Utility {
  public static List<IFoo> GetFoos(DateTime since) {...}
  public static void SaveBazes(List<IBaz> bases) {...}
 }
}

namespace MyCompany.Integrations.System2 {
 public static class Utility {
  public static void SaveFoos(List<IFoo> foos) {...}
  public static List<IBar> GetBars(DateTime since) {...}
 }
}

namespace MyCompany.Integrations.System3 {
 public static class Utility {
  public static void SaveFoos(List<IFoo> foos) {...}
  public static void SaveBars(DateTime since) {...}
 }
}

Quest开发者_高级运维ion: What existing patterns, if any, is this similar to and are there any areas I might explore to help me learn how to improve my architecture? I know the Utility classes aren't OO. I haven't figured out how to layout classes to get it done in a simple way yet.

Addition: I thought more and based on one response, I think I was not specific enough. I am hoping someone who had more experience tells me how to apply some OO patterns and get away from Utility classes

10,000 foot answer:

You might find Domain Driven Design and Clean Code useful as they give you a set of patterns that work well together and a set of principals for evaluating when to apply a pattern. DDD resources: the book, free quick intro, excellent walkthrough. Clean Code resources: summary, SOLID principles.

Specific answer:

You are already using the Repository pattern (your utility classes) which I'd probably use here as well. The static members can make the code difficult to test but otherwise aren't a problem. If the Repositories become too complex, break out the low-level API communication into Gateways.

Since an entity is split across multiple data sources, consider modelling this explicitly. For example: Person, HumanResourcesPerson, AccountingPerson. Use names understood by the external systems and their business owners (e.g. Employee, Resource). See Single Responsibilty Principle and Ubiquitous Language for some reasoning. These may be full Entities or just Data Transfer Objects (DTOs) depending on how complex they are.

The synchronization might be performed by an Application Service that coordinates the Repositories and Entities.

It sounds like you are wanting a Finder pattern that can locate repositories, is my understanding correct? If so then research on the Finder Pattern in Google there should be some info on it.

I have done a quick search and located this:

http://martinfowler.com/articles/injection.html