PHP’de Otomatik Bağlama vs. Açık Bağlama: Büyü Ne Zaman Size Mal Olur

Bir servise bir constructor argümanı ekliyorsunuz. Yazdığınız yeni bir arayüz. Uygulamayı çalıştırıyorsunuz ve her şey yolunda. Hiçbir konfigürasyon değişmedi, hiçbir fabrika düzenlenmedi, hiçbir şey kaydedilmedi. Container, tip hint’i gördü, onu uygulayan tek bir sınıf buldu ve sizin için tanımladı.

Bu, autowiring’in tam olarak vaat ettiği şeyi gerçekleştiği anlamına geliyor. Constructor’ı okudu, tipi somut bir sınıfa eşleştirdi ve objeyi bir satır yapıştırıcı kod yazmadan oluşturdu. Bir Symfony veya Laravel servisi için, bir arayüz başına sadece bir uygulama varsa, doğru yaklaşım budur.

Şimdi şekli değiştirin. O arayüzün ikinci bir uygulamasını yazdınız. Uygulamayı çalıştırıyorsunuz ve hata alıyorsunuz:

Cannot autowire service "App\Order\PlaceOrder":
argument "$gateway" of method "__construct()"
references interface "App\Port\PaymentGateway"
but no such service exists. You should maybe
alias this interface to one of these existing
services: App\Payment\StripeGateway,
App\Payment\AdyenGateway.

Container, cevap benzersiz olmayı durdurduğunda, kendinden emin olmaktan kararsızlığa geçti. İki uygulama olduğunda, şimdi bir karar borcunuz var ve tek soru bu kararı nerede yazacağınız.

Autowiring aslında ne yapar

Autowiring, yansıma ve bir arama tablosudur. Container, bir sınıfı inşa etmesi gerektiğinde, constructor parametrelerini okur ve her tip hint’li argüman için sorar: bu tip için kayıtlı bir servis var mı? Varsa, ona döner ve o da inşa eder. Eğer tip tam olarak bir adaya karşılık geliyorsa, eşleşme sessiz ve doğrudur.

Symfony’de varsayılan services.yaml bunu kendi ad alanınız için etkinleştirir:

services:
    _defaults:
        autowire: true
        autoconfigure: true
<span class="na">App\</span><span class="pi">:</span>
    <span class="na">resource</span><span class="pi">:</span> <span class="s1">'</span><span class="s">../src/'</span>
    <span class="na">exclude</span><span class="pi">:</span>
        <span class="pi">-</span> <span class="s1">'</span><span class="s">../src/Domain/'</span>
        <span class="pi">-</span> <span class="s1">'</span><span class="s">../src/Kernel.php'</span>
 

App\ altındaki her sınıf bir servis haline gelir ve constructor argümanları tip ile çözülür. Laravel de aynı şeyi container’ı üzerinden yapar: app()->make(SomeClass::class) constructor’u yansıtır ve her bağımlılığı, sıfır kayıt ile, geriye doğru çözer.

Bir Request, bir logger ve bir uygulama ile altı olan bir repository’ye ihtiyaç duyan bir controller için, bu geçerli bir miktar laf: hiçbiri. Tip hint’leri belirsiz değildir, ağ yüzeydir ve el ile bir fabrika yazmak gürültü eklemekten başka bir şey yapmaz.

Büyülü şeyler sizi zorlamaya başladığında

Fatura, tip hint’inin benzersiz cevap olmaktan çıkmasıyla gelir. Üç durum sürekli karşıma çıkmaktadır.

Bir arayüzün iki uygulaması. Yukarıdaki örnek PaymentGateway. Container seçemez. Artık ona bir karar borcunuz var ve tek soru bu kararı nerede yazacağınızdır.

Bir scalar veya container’ın tahmin edemediği bir değer. Bir adaptörın bir temel URL, bir zaman aşımı, bir API anahtarı gerekir. string $endpoint ile eşleşecek bir tip yoktur. Autowiring’in alacağı bir şey yoktur.

final readonly class HttpPaymentGateway
    implements PaymentGateway
{
    public function __construct(
        private ClientInterface $http,
        private string $endpoint,
        private int $timeoutSeconds,
    ) {}
}

$http tip ile çözülüyor. $endpoint ve $timeoutSeconds çözülmüyor, ve container ya başarısız olur ya da daha kötüsü, varsayılanlarla dikkatsizseniz, boş bir dizeyi sessizce enjeksiyon yapar.

Bir dekoratör veya sarmalanmış instance. PlaceOrderı bir işlem dekoratörüne sarmalamak istiyorsunuz. Container kendi başına neyi sarmalamak istediğinizi bilmez. O yalnızca çıplak bir PlaceOrder oluşturacak ve bunu verecek, ve düşünmüş olduğunuz işlem sınırı hiç var olmamış olacak.

Bunlar kenar durumları değildir. Bunlar dış dünyayla iletişim kuran her servisin normal şeklidir ve bunlar iş anlamı taşıyan tam olarak o kablolama kararlarıdır. Kalıp şu: bağlama daha önemliyse, autowiring bunun tahmin edemeyeceği kadar azdır ve daha görünür hale getirmek istersiniz.

Göremediğiniz grafik

Burada daha sessiz bir maliyet var. Olgun bir Symfony uygulaması açın ve çalıştırın:

php bin/console debug:container --show-arguments

Yüzlerce hizmet alırsınız, bunların çoğu yansıma ile bağlanmıştır. Bağımlılık grafiği gerçektir, yük taşıyan bir yapıdır ve onu yukarıdan aşağıya okuyabileceğiniz hiçbir yerde yaşamaz. “Bir sipariş verildiğinde ne olur?” diye sorulduğunda, dürüst cevap, constructor’ı okumak, her arayüzü kendine ait ismiyle takip etmek, sonra her ismi uygulamaya takip ederek iç içe geçmiş olarak bakmak gerekir.

Grafik var. Sadece onu tek bir yerde göremiyorsunuz. Yeni bir mühendis “sipariş verildiğinde ne olur?” dediğinde, doğru cevap bir tip hint’i ve container isimlerine göz atmakle başlar.

Bunu grafiği veri olarak ifade eden bir dosyayla karşılaştırın:

$c->set(Clock::class, fn() => new SystemClock());
$c->set(PaymentGateway::class, fn(C $c) =>
new HttpPaymentGateway(
$c->get(ClientInterface::class),
$_ENV['PAYMENT_GATEWAY_URL'],
timeoutSeconds: 5,
),
);
$c->set(OrderRepository::class, fn(C $c) =>
new DoctrineOrderRepository(
$c->get(EntityManagerInterface::class),
$c->get(OrderRecordMapper::class),
),
);
$c->set(PlaceOrder::class, fn(C $c) =>
new TransactionalDecorator(
new PlaceOrder(
$c->get(CustomerRepository::class),
$c->get(OrderRepository::class),
$c->get(PaymentGateway::class),
$c->get(EventBus::class),
$c->get(Clock::class),
),
$c->get(EntityManagerInterface::class),
),
);

Bir kez okuduğunuzda, tüm hikayeyi biliyorsunuz. Hangi adaptörün hangi porta destek verdiği. Zaman aşımının nereden geldiği. O PlaceOrder‘ın sarıldığı ve kiminle sarmalandığı. Yansıma ile takip etmeniz gereken hiçbir şey yok, takip etmeniz gereken başka bir isim yok. Dekoratör, kodun içinde, bir konfigürasyon geleneği ile ima edilmemiştir.

Çizilmesi gereken sınır

Uygulamada uygulanabilir olan bölünme: sıksa sıkıcı olanları autowire yapın, alanı el ile bağlayın.

Container’ın autowire etmesine izin verin controller’lar, olay aboneleri, konsol komutları, form tipleri, çerçeve yapıştırıcıları için. Bunların yüzeysel grafikleri, benzersiz bağımlılıkları vardır ve yapılarında gizli iş kararları yoktur. Yansıma bunları doğru bir şekilde çözer ve el ile bu nesneler için fabrika yazmak gereksiz bir iştir.

Alan kullanım durumlarını ve portlarını açıkça bağlayın, sahip olduğunuz tek bir kompozisyon kökünde. PlaceOrder, CancelOrder, repository’ler, gateway’ler, dekoratörler. Bunlar bağlamadaki bir seçimlerin tasarım seçimleri olduğu nesnelerdir: hangi depolama backend’i, hangi ödeme sağlayıcısı, bir işlemin çalışıp çalışmayacağı. O bağlamaları el ile yazmak bir yük değildir. Yazma süreci tam olarak anlam ifade eden bir süreçtir. Dosya, uygulamanızın gerçek yapısının haritası haline gelir.

Symfony’de bunu yapmak için framework tarafından çıkarılmak zorunda değilsiniz. Framework katmanında autowiring’i açık tutarak, alan katmanındaki açılışlarla birlikte açık tanımlara geçebilirsiniz:

services:
    _defaults:
        autowire: true
        autoconfigure: true
<span class="na">App\</span><span class="pi">:</span>
    <span class="na">resource</span><span class="pi">:</span> <span class="s1">'</span><span class="s">../src/'</span>
    <span class="na">exclude</span><span class="pi">:</span>
        <span class="pi">-</span> <span class="s1">'</span><span class="s">../src/Domain/'</span>
        <span class="pi">-</span> <span class="s1">'</span><span class="s">../src/Application/'</span>

<span class="c1"># alan kablolama, el ile ifade edilen</span>
<span class="na">App\Application\Order\PlaceOrder</span><span class="pi">:</span>
    <span class="na">arguments</span><span class="pi">:</span>
        <span class="na">$orders</span><span class="pi">:</span> <span class="s1">'</span><span class="s">@App\Infrastructure\Persistence\Doctrine\DoctrineOrderRepository'</span>
        <span class="na">$payments</span><span class="pi">:</span> <span class="s1">'</span><span class="s">@App\Infrastructure\Payment\HttpPaymentGateway'</span>

<span class="na">App\Infrastructure\Payment\HttpPaymentGateway</span><span class="pi">:</span>
    <span class="na">arguments</span><span class="pi">:</span>
        <span class="na">$endpoint</span><span class="pi">:</span> <span class="s1">'</span><span class="s">%env(PAYMENT_GATEWAY_URL)%'</span>
        <span class="na">$timeoutSeconds</span><span class="pi">:</span> <span class="m">5</span>
 

Framework sınıfları autowired kalıyor. Kullanım durumu ve adaptörleri açıkça adlandırılmıştır, böylece grafiğin ilginç kısmı bir yerde veri olarak okunabilir. Hiçbir şeyin varsayılan olarak tahmin edilmesine izin vermeden, gerçekten bir görünürlük elde edersiniz.

Bir uygulama ikiye dönüştüğünde

Bir bağlama tarzının gerçek testi, bir değişikliğin neye mal olduğudur. Diyelim ki bir özellik bayrağı arkasında ikinci bir ödeme sağlayıcısı eklersiniz.

Tüm bağlamaları autowired yaptığınızda, önce “autowire edilemez, böyle bir servis yok” hatasıyla karşılaşırsınız, ardından bir container alias’a veya #[Target] attribute’ine ya da bir derleyici geçişine başvurursunuz ve hangi gateway’in aktif olduğuna dair karar üç dosya arasında dağılır.

Açık bir kompozisyon köküyle, değişiklik yerel ve okunabilir olur:

$c->set(PaymentGateway::class, fn(C $c) =>
    $_ENV['PAYMENT_PROVIDER'] === 'adyen'
        ? new AdyenGateway(/* ... */)
        : new StripeGateway(/* ... */),
);

Karar, kararların yer aldığı dosyada yer alır. Bir gözden geçiren kişi dalı, iki sağlayıcıyı görür, seçen env değişkenini görür. Hiçbir şey gelenekten dolayı ima edilmiyor. Büyü, framework katmanında kaybolmadı; sadece tahminlerin pahalı olduğu katmanlardan uzak tutuldu.

Genel kural

Her bağlama için bir soru sorun: eğer bu yanlış olsaydı, başarısızlık sesli mi yoksa sessiz mi olurdu?

Eksik bir controller bağımlılığı, başlangıçta sesi yüksek bir şekilde başarısız olur. Autowiring bunu halletsin. Yanlış bir ödeme gateway’i, eksik bir işlem sarmalayıcı, sessizce varsayılan olarak sıfıra dönen bir zaman aşımı — bunlar sessizce, üretimde, Cuma günü başarısız olur. Bunları insana okunacak bir yerde yazın.

Autowiring, sistemin benzersiz bir cevabı olduğu yerlerde ve yanlış bir hatanın maliyeti bir başlangıçta bir yığın izleme olduğu yerlerde iyi bir varsayılandır. Kompozisyon kökü, cevapların bir seçim olduğu ve hatanın maliyetinin kimsenin hoşlanmadığı bir hata ayıklama oturumu olduğu yerler içindir.

Alan bağlamalarını açık tutmak, bir kompozisyon kökünde uygulamanın sahip olduğu, çerçevenin altında gizlice iş mantığınızı oluşturma yerine, kodu çerçeveden çıkartmasına izin veren bir dikiş yeridir. Container, birkaç adaptörden biri olduğunda ve iş mantığınızı gizlice bir araya getirdiğinizde, onu değiştirmek bir öğleden sonradan daha fazla olmaz, yeniden yazma sürecine dönüşmez. Decoupled PHP kitabının tüm argümanı bu sınırdır: çerçeve bir eklenti, alan el ile bağlanmıştır.