Объединение стратегии и паттернов декоратора в системе агрегации данных PHP ⇐ Php

[Anonymous]

Я работаю над довольно большим проектом PHP, где мне нужно получить данные из нескольких источников (например, из разных API, баз данных и т. д.), а затем выполнить некоторую постобработку. Моя идея заключалась в том, чтобы использовать шаблон «Стратегия» для переключения между различными поставщиками данных (например, MySQL, внешним REST API и т. д.), а затем использовать шаблон «Декоратор», чтобы добавить поверх него поведение кэширования. Но, честно говоря, мой подход становится очень запутанным, и я даже не уверен, что это правильный путь.
Позвольте мне показать вам упрощенную версию того, что я делаю. :
interface DataProvider
{
public function getData(array $params): array;
}

class MySQLProvider implements DataProvider
{
public function getData(array $params): array
{
// Hypothetical MySQL fetch
// e.g. $pdo->query("SELECT * FROM table WHERE...");
return ['source' => 'MySQL', 'data' => ['foo', 'bar']];
}
}

class RestAPIProvider implements DataProvider
{
public function getData(array $params): array
{
// Hypothetical REST API call
// e.g. file_get_contents("https://api.example.com/data");
return ['source' => 'REST_API', 'data' => ['baz', 'qux']];
}
}

// Simple context for Strategy
class DataContext
{
private DataProvider $provider;

public function __construct(DataProvider $provider)
{
$this->provider = $provider;
}

public function fetch(array $params): array
{
return $this->provider->getData($params);
}
}

// Decorator to add caching (my attempt)
class CachingDecorator implements DataProvider
{
private DataProvider $wrappedProvider;
private array $cache = [];

public function __construct(DataProvider $wrappedProvider)
{
$this->wrappedProvider = $wrappedProvider;
}

public function getData(array $params): array
{
$key = md5(json_encode($params));
if (!isset($this->cache[$key])) {
$this->cache[$key] = $this->wrappedProvider->getData($params);
}
return $this->cache[$key];
}
}

// Sample usage
// Strategy choice (pretend we pick MySQL vs REST based on config)
$provider = (rand(0,1) === 1) ? new MySQLProvider() : new RestAPIProvider();
$cachedProvider = new CachingDecorator($provider);
$context = new DataContext($cachedProvider);

$result = $context->fetch(['user' => 'test', 'limit' => 10]);
var_dump($result);
< /code>
Приведенный выше код несколько в порядке для основного примера, но в моем реальном коде есть гораздо больше поставщиков данных и более сложные правила кэширования. Я смешиваю все вместе, и он начинает чувствовать, что я взламываю его, а не проектирую его. Например: < /p>

У меня есть несколько слоев кэширования, каждый с разными правилами (некоторые должны кэшировать все, некоторые должны делать частичное кэширование). < /Li>
Я хочу сделать какую -то запасную логику (например, если MySQL не удастся, автоматически переключиться на API REST). был выбран и тип данных. < /li>
< /ol>
Мне интересно, есть ли другой шаблон (или, может быть Полем Будет ли использование стратегии + декоратора таким образом взорваться по мере роста числа поставщиков и слоев кэширования? Может ли цепочка ответственности или абстрактной фабрики помочь мне лучше справиться с логикой резервного или динамического поставщика? Я видел такие предложения, как «просто используйте контейнер DI или локатор сервиса», но это кажется, что он решает только половину проблемы. верхняя часть друг друга, а также разрешает источники данных запасных данных? Как бы вы это структурировали, так что он гибкий, но не стал кошмаром для поддержания?

Подробнее здесь: https://stackoverflow.com/questions/793 ... ion-system