Yaşam süreleri ve arayüzler

Singleton, Scoped ve Transient arasında seçim yapın; servisleri arayüzleri üzerinden çözün.

Yaşam süresi, bir servis instance’ının ne zaman oluşturulacağını, kimlerle paylaşılacağını ve kimin tarafından temizleneceğini belirler. Örneklerde yaşam süresini açıkça yazın.

Yaşam süresi seçimi#

Yaşam süresi	Oluşturulma	Paylaşım	Temizleme
`Singleton`	Container build sırasında	Container içindeki bütün işler	Container kapanışı
`Scoped`	Scope’ta ilk çözümleme	Aynı istek veya iş	Scope kapanışı
`Transient`	Her çözümleme	Paylaşılmaz	Çözümlendiği scope; scope yoksa container

#[service] içinde lifetime belirtilmezse varsayılan Transient’tır. Connection pool gibi uygulama kaynakları Singleton, isteğin transaction context’i Scoped olabilir.

Bağımlılıkların yaşam süreleri#

Singleton bir Scoped servisi tutamaz. Araya Transient bir servis koymak da scope ihtiyacını ortadan kaldırmaz: startup sırasında aktif scope yoktur. Doğrudan lifetime hatası ile dolaylı çözümleme hatası aynı doğrulama aşamasında çıkmak zorunda değildir.

Singleton → Transient mümkündür. Ancak Singleton’ın tuttuğu o instance root ömrüne bağlanır. Her kullanımda yeni instance alınmış olmaz.

Scope, Arc sayacı değildir. Scoped servisin Arc değerini istek dışına taşımak scope’un yaşam süresini uzattığınız anlamına gelmez. Her bağımsız iş için kendi scope’unu açın.

Arayüz üzerinden injection#

Bir servisi concrete türü yerine davranış sözleşmesiyle kullanabilirsiniz. Aşağıdaki parçada Greeting uygulamaya ait bir trait, GreetingService ise onun ServiceTrait uygulayan servisidir:

#[service(interface = dyn Greeting, lifetime = "Singleton")]
// GreetingService üzerinde #[derive(Injectable)] ile birlikte kullanılır.

#[inject]
greeting: Arc<dyn Greeting>,

Action’da Service<dyn Greeting> aynı interface kaydından çözülür. Aynı interface için birden fazla aktif implementation build hatasıdır. Concrete ve interface çözümlemeleri kayıtlı lifetime’a uyar; Transient için iki resolve aynı allocation’ı paylaşmaz.

Testlerde başlangıç değeri verme#

ApplicationContainer::builder().seed_singleton(value), zaten kayıtlı bir Singleton’ın başlangıç instance’ını değiştirir. Yeni bir servis kaydı eklemez. Bilinmeyen tür, Scoped/Transient tür veya aynı türün tekrarlı seed edilmesi reddedilir.

Eksik dependency, cycle, duplicate interface ve yaşam süresi hataları startup’ta ele alınır. Container’ı endpoint içinde yeniden kurmak yerine uygulamanın mevcut provider’ını kullanın.