Help with Repository(ies) method

Question

I am new to this repository lark, so some help is gratefully received.

I am trying to design a method to have a central payment website for all our sites. The sites will populate a table that return a GUID. All the sites will pass the GUID across to the central payment site. The central payment site will look at the querystring and use the GUID to retrieve the details concerning the order and which site called it. I am trying to make it flexible, so the following 1) Different payment providers can be used at a given time (ie Paypal, Google Check) without major hassel 2) Different DB(orm) layers can be used (we use subsonic at the moment, but could use LINQ etc)

I am not sure how to implement this. Any suggestions?

Thanks

Podge

Answer 1

Start by creating a services layer and then just use an interface to abstract it - would be my starting suggestion.

public interface IPaymentService
{
  Guid PopulateTable();
  Order GetOrder(Guid id);
}

public class PayPalPaymentService : IPaymentService
{
  public Guid PopulateTable() { ... }
  public Order GetOrder(Guid id) { ... }
}

public class GooglePaymentService : IPaymentService
{
  public Guid PopulateTable() { ... }
  public Order GetOrder(Guid id) { ... }
}

The suppose you could substitute "Repository" for "Service" as I think that's what you're after but I think your idea of a Repository is a bit different.

I'd use a repository to handle querying to the database...

Those would look more like:

T Get<T>(Guid id);
IList<T> FindAll<T>(Guid fid);

Which would be used by PayPal and Google services(/repository).

Answer 2

First consider this is a good place to apply bounded context: http://domaindrivendesign.org/discussion/messageboardarchive/BoundedContext.html. Ideally you shouldn't be integrating different (sub)systems through the database. This should be happening at the api level. You might already have it structured like that, assuming:

• The "table" all the sites are populating isn't a single shared information for all the sites. What it is really about is each site saving whatever info it needs about the process it is about to start, and getting an ID that will hand to the payment system.
• The payment system shouldn't force unique Ids across different web sites. It can force that each web site sends an unique id in their own context.
• If the payment system needs extra information, it should also require it at the API level, instead of forcing a db relation between all the sites and the payment system.

You can have the sites call an API on the payment site to start the payment process and then redirect to the site. You can use either an ID controlled by each web site, or a common ID that the payment site returns after the initial payment call.

With that in mind, the repositories would be use internally and independent by the sites and the payment service to persist information. This doesn't necessarily means it has to be a DB, as you can persist information to other places/mechanisms.