MediatR pipeline’da istek doğrulama

Her command handler'ın başında aynı alan kontrolleri bulunuyorsa tekrarın yeri iş metodu değil, ortak giriş hattı olabilir. MediatR pipeline behavior, handler'dan önce ve sonra çalışan bir sarmalayıcı sunar. Arşivimdeki oluşturma, güncelleme ve yayımlama akışlarını anlatırken doğrulamayı burada toplamak, işleyicinin asıl kararını daha okunur bırakır.

Handler'a geçiş noktası next

Aşağıdaki parça MediatR 12.x delegate biçimini ve FluentValidation'ı esas alıyor. Projede kurulu sürümle imzalar ve DI kayıt API'leri eşleştirilmeli; buradaki amaç en yeni pakete yükseltme önerisi yapmak değil. Behavior tek başına çalışan API veya tamamlanmış kayıt işlemi değildir.

using FluentValidation;
using MediatR;
public sealed class ValidationBehavior<TRequest,TResponse>(
    IEnumerable<IValidator<TRequest>> validators):IPipelineBehavior<TRequest,TResponse>
    where TRequest:notnull
{
    public async Task<TResponse> Handle(TRequest request,RequestHandlerDelegate<TResponse> next,CancellationToken token)
    {
        var errors=new List<FluentValidation.Results.ValidationFailure>();
        foreach(var validator in validators)
        {
            var result=await validator.ValidateAsync(new ValidationContext<TRequest>(request),token);
            errors.AddRange(result.Errors);
        }
        if(errors.Count>0)throw new ValidationException(errors);
        return await next();
    }
}

İlgili TRequest için kayıtlı validator'lar çözülür, her biri ValidateAsync ile çalışır ve hatalar toplanır. Hata varsa next çağrılmaz, dolayısıyla handler'a ulaşılmaz. Validator yoksa döngü boştur ve istek normal devam eder. Sonraki pipeline halkasına geçişin tek bir noktada olması, kesilen ve yürüyen yolları görünür kılar.

Neden hepsini Task.WhenAll ile başlatmıyorum?

Validator'lar aynı Scoped DbContext'i veya başka bir eşzamanlı kullanıma uygun olmayan servisi paylaşabilir. Hepsini paralel çalıştırmak sırf daha kısa yazıldığı için güvenli değildir. Bu örnek kuralları sırayla yürütür. Paralellik gerekiyorsa bağımlılıkların bağımsızlığı ve toplam kaynak kullanımı ayrıca gösterilmeli; veri erişim nesnelerinin kullanım sözleşmesi ihlal edilmemeli.

CancellationToken her doğrulamaya iletilir. Bir async kural alt servise çağrı yapıyorsa o çağrı da iptali almalı. Doğrulama hattını çok sayıda pahalı sorguyla doldurmak ise çoğu zaman alan kontrolünden iş orkestrasyonuna kayıldığını gösterir.

DI'ye kaydetmeden behavior çalışmaz

Handler'ın bulunduğu assembly'nin taranması ve open generic behavior kaydı gerçek host'ta yapılmalıdır. Yalnız sınıfı projeye eklemek bütün istekleri otomatik yakalamaz. İlgili MediatR 12.x kayıt biçiminde aşağıdaki parça, projedeki gerçek assembly ve validator kayıtlarıyla birlikte kullanılabilir:

services.AddMediatR(config =>
{
    config.RegisterServicesFromAssemblyContaining<Program>();
    config.AddOpenBehavior(typeof(ValidationBehavior<,>));
});

Bu kayıt validator tiplerini sihirli biçimde üretmez; onlar da DI'ye eklenmelidir. Program'ın erişilebilir olmadığı ayrı bir assembly'de handler'a ait başka bir marker tip seçilebilir. Kullanılan paket sürümünün lisans ve bakım koşulları da uygulamanın bağımlılık kararıdır.

ValidationException'ı HTTP sınırında çevirmek

Bu MediatR örneği başarısızlığı ValidationException ile bildiriyor. İş servisinin beklenen sonucunu ServiceResult ile döndürmek farklı bir yaklaşımdır; ikisini aynı hata için gelişigüzel karıştırmam. Exception seçilmişse API middleware'i bunu alan hataları içeren kontrollü 400 yanıtına çevirmeli. İç stack trace kullanıcıya dönmemeli ve hata yanlışlıkla 500 gibi sunulmamalı.

Pipeline'ın yalnız HTTP'den çağrılmayabileceğini de unutmam. Aynı command worker veya testten gönderilebilir. Bu nedenle behavior IActionResult üretmez; taşıma katmanına bağımlı olmaz.

Transaction ve iş kurallarıyla sıra ilişkisi

Yetkisiz isteğin veri sorgulamaması, ucuz biçim kontrollerinin yazma transaction'ından önce olması gibi hedefler pipeline sırasını etkiler. Bunun tek evrensel sırası yok; kullanılan davranışların neyi sardığı anlaşılmalı. “Bu kayıt yayımlanabilir mi?” gibi durum kuralı ise handler/serviste kalır ve eşzamanlı değişikliklere karşı transaction içinde korunabilir.

Geçersiz istekte handler çağrı sayısının sıfır olduğunu, geçerli istekte tam bir kez çalıştığını sınarım. Birden çok validator hatasının birleşmesi, validator bulunmaması ve iptal de ayrı testlerdir. Böylece yalnız sınıfın derlenmesini değil gerçek gönderim hattına katılmasını doğrulamış olurum.

MediatR behavior modeli; Validator DI kayıtları.