В настоящее время я работаю над php-фреймворком, чтобы абстрагироваться и сделать его интересным и простым в работе с внешним программным обеспечением ($ ES), к которому обращается моя компания. Мой подход — шестиугольная модель дизайна, которая до сих пор прекрасно работает. Моя единственная задача — сопоставить (и где отобразить) сущности из $ ES с нашей внутренней структурой.
Пример:
$ externalSoftwareProduct (своего рода класс бога, который обрабатывает все)
сопоставляется с $ internalFrameworkProduct (и многими другими классами для разделения обязанностей). Это происходит в репозиториях. В каждом методе хранилища я собираю эти сущности из $ ES и делаю
new $internalFrameworkProduct(some arguments here coming from
$externalSoftwareProduct)
foreach из моих собранных сущностей, которые затем возвращаются. В этих репозиториях есть только общие методы, такие как getById, getAll, вы называете это.
Теперь мы используем эту инфраструктуру в проекте заказчика и расширяем эти базовые классы с помощью расширения, специфичного для домена, например CustomerNameProductRepository.
Там вы найдете специфичные для домена методы, такие как getProductsCustomerAlwaysNeeds и так далее. В конце этих методов мы сопоставляем $ internalFrameworkProduct с $ customerSpecificProduct, который содержит данные для более легкого доступа, который необходим. Метод в этом конкретном репозитории выглядит следующим образом.
public function getProductsCustomerAlwaysNeeds()
{
$dataStuff = parent::getSomeStuff();
/** @var internalFrameworkProduct[] $products **/
$products = magic();
foreach($products as $product)
{
$customerProducts[] = $this->getCustomerSpecificProduct($product->getId());
}
return $customerProducts;
}
public function getCustomerSpecificProductById(int $productId)
{
$externalSoftwareProduct = new externalSoftwareProduct($productId)
$customerSpecificProduct = new CustomerSpecificProduct(some arguments here coming from $externalSoftwareProduct)
return $customerSpecificProduct;
}
Теперь это работает отлично до сих пор. Единственная проблема в модульных тестах. Мы используем phpunit + Mockery. Чтобы смоделировать эти новые созданные экземпляры, мы должны использовать mock (перегрузка: externalSoftwareProduct) и mock (перегрузка: CustomerSpecificProduct), что всегда является проблемой (особенно если вы пытаетесь проверить это с несколькими экземплярами, что время от времени требуется) ,
Как бы вы подошли к этому? Должен быть лучший способ подключить эти 3 части (externalSoftwareProduct, internalFrameworkProduct и CustomerSpecificProduct (который расширяет internalFrameworkProduct)).
Я думал об использовании фабрики для CustomerSpecificProduct, чтобы просто издеваться над фабрикой и позволить ей выплевывать мои продукты. Но я чувствую, что я перерабатываю такую простую задачу.
«…. сопоставление (и где сопоставить) сущностей из $ ES с нашей внутренней структурой …»
В адаптере вы используете для доступа к внешнему программному обеспечению.
Других решений пока нет …