Помощь с методом репозитория

Question

Я новичок в этом жаворонке хранилища, поэтому с благодарностью получаем некоторую помощь.

Я пытаюсь разработать метод, позволяющий создать центральный платежный веб-сайт для всех наших сайтов. Сайты будут заполнять таблицу, которая возвращает GUID. Все сайты передают GUID на центральный платежный сайт. Центральный платежный сайт просматривает строку запроса и использует GUID для получения подробной информации о заказе и о том, какой сайт его вызвал. Я пытаюсь сделать это гибким, поэтому следующее 1) В данный момент могут использоваться разные платежные системы (например, Paypal, Google Check) без каких-либо серьезных проблем. 2) Можно использовать разные слои БД (orm) (в настоящее время мы используем дозвуковые, но могли бы использовать LINQ и т. Д.)

Я не уверен, как это реализовать. Есть предложения?

Спасибо

Толстяк

Answer 1

Во-первых, подумайте, что это хорошее место для применения ограниченного контекста: http://dddcommunity.org/discussion/messageboardarchive/BoundedContext.html. В идеале не следует интегрировать различные (под) системы через базу данных. Это должно происходить на уровне API. Вы, возможно, уже структурировали это так, предполагая:

• «Таблица», которую заполняют все сайты, - это не единая общая информация для всех сайтов. На самом деле каждый сайт сохраняет любую необходимую ему информацию о процессе, который он собирается запустить, и получает идентификатор, который будет передан платежной системе.
• Платежная система не должна устанавливать уникальные идентификаторы на разных веб-сайтах. Это может заставить каждый веб-сайт отправлять уникальный идентификатор в своем собственном контексте.
• Если платежная система нуждается в дополнительной информации, она также должна требовать ее на уровне API, вместо того чтобы навязывать связь между всеми сайтами и платежной системой на основе базы данных.

Вы можете попросить сайты вызвать API на сайте оплаты, чтобы начать процесс оплаты, а затем перенаправить на сайт. Вы можете использовать либо идентификатор, контролируемый каждым веб-сайтом, либо общий идентификатор, который сайт оплаты возвращает после первоначального платежного вызова.

Учитывая это, хранилища будут использоваться внутренне и независимо сайтами и платежной службой для сохранения информации. Это не обязательно означает, что это должна быть БД, поскольку вы можете сохранять информацию в других местах / механизмах.

Answer 2

Начните с создания слоя сервисов, а затем просто используйте интерфейс для его абстрагирования - это будет мое начальное предложение.

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) { ... }
}

Предположим, вы могли бы заменить "Репозиторий" на "Сервис", так как я думаю, что это то, что вам нужно, но я думаю, что ваша идея Репозитория немного отличается.

Я бы использовал репозиторий для обработки запросов к базе данных ...

Это будет выглядеть примерно так:

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

Что будет использоваться PayPal и службами Google (/ репозиторий).