DTO Pattern

DTO Modeli veya Data Transfer Object Modeli, bir uygulamanın farklı bölümleri arasında yapılandırılmış verileri aktarmak için kullanılan bir yazılım tasarım modelidir. DTO, kod tabanının her yerinde dahili modelleri, database varlıklarını, istek nesnelerini veya ham dizileri açığa çıkarmadan verileri taşıyan basit bir nesnedir.

DTOs, nesne yönelimli uygulamalarda, APIs, Laravel projelerinde, Symfony uygulamalarında, clean architecture, hizmet katmanlarında, komut işleyicilerinde, harici entegrasyonlarda ve veri dönüştürme iş akışlarında yaygın olarak kullanılır. Geliştiricilerin veri akışını daha net, daha güvenli ve bakımı daha kolay hale getirmesine yardımcı olurlar.

Giriş

Bu OOP ve Design Patterns serisinin önceki makalelerinde, MVC Modeli, Service Layer Modeli, Repository Pattern, Dependency Injection, Command Pattern, Observer Pattern gibi kalıpları tartıştık. Strategy Pattern, Adapter Pattern ve Facade Pattern.

DTO Modeli özellikle veriler bu katmanlar arasında hareket ederken kullanışlıdır. Örneğin, bir denetleyici istek verilerini alabilir, bunu bir hizmete iletebilir ve hizmet, yapılandırılmış verileri bir depoya, komuta, olaya veya harici API bağdaştırıcısına iletebilir.

DTOs olmadan geliştiriciler genellikle ham dizileri uygulama genelinde aktarır. Bu ilk başta işe yarayabilir, ancak proje büyüdükçe dizilerin anlaşılması zorlaşır, doğrulanması zorlaşır ve kötüye kullanılması kolaylaşır. DTOs, verilere net bir yapı vererek bu sorunu çözer.

DTO Nedir?

DTO veya Data Transfer Object, esas olarak verileri bir katmandan diğerine taşımak için oluşturulmuş bir nesnedir. Genellikle özellikleri ve bazen basit yardımcı yöntemleri içerir ancak karmaşık business logic içermemelidir.

Basit bir ifadeyle DTO, veriler için yapılandırılmış bir kapsayıcıdır.

Örneğin, geliştirici, ad, e-posta, parola ve telefon gibi anahtarları içeren bir kullanıcı kayıt dizisini iletmek yerine bir RegisterUserDto oluşturabilir. Bu nesne, kullanıcı kaydı için hangi verilerin gerekli olduğunu açıkça tanımlar.

DTO Modeli Neden Önemlidir?

DTO Modeli önemlidir çünkü veri aktarımını açık hale getirir. Bir yöntem bir diziyi aldığında hangi anahtarların beklendiği her zaman açık değildir. Dizide eksik değerler olabilir, fazladan değerler bulunabilir veya yanlış anahtar adları kullanılmış olabilir.

DTO ile beklenen veriler tek bir sınıfta tanımlanır. Bu okunabilirliği artırır ve hataları azaltır.

DTOs ayrıca dahili modellerin korunmasına da yardımcı olur. Uygulama, database modellerini her yere iletmek veya nesneleri talep etmek yerine, yalnızca belirli bir işlem için gereken değerleri içeren temiz veri nesnelerini iletebilir.

DTOs Olmadan Sorun

Ham dizi alan bir kullanıcı kayıt hizmeti düşünün:

class UserRegistrationService
{
    public function register(array $data): User
    {
        return User::create([
            'name' => $data['name'],
            'email' => $data['email'],
            'password' => password_hash($data['password'], PASSWORD_BCRYPT),
        ]);
    }
}

Bu kod çalışıyor ancak hizmet, hangi verileri beklediğini açıkça iletmiyor. Dizinin bir telefon numarasına ihtiyacı var mı? Bir rol içeriyor mu? E-posta zaten doğrulanmış mı? Şifre anahtarı eksikse ne olur?

Ham diziler esnektir ancak bu esneklik gizli hatalar yaratabilir. DTOs daha net bir sözleşme sağlar.

DTO Modeli ile Çözüm

Bir DTO beklenen verileri açık hale getirebilir:

class RegisterUserDto
{
    public function __construct(
        public string $name,
        public string $email,
        public string $password
    ) {
    }
}

Hizmet artık ham dizi yerine DTO'yu alabiliyor:

class UserRegistrationService
{
    public function register(RegisterUserDto $dto): User
    {
        return User::create([
            'name' => $dto->name,
            'email' => $dto->email,
            'password' => password_hash($dto->password, PASSWORD_BCRYPT),
        ]);
    }
}

Bu kod daha açıktır. Yöntem imzası, geliştiricilere tam olarak ne tür verilerin gerekli olduğunu söyler.

DTOs'nun Ana Amacı

DTOs'nun temel amacı, verileri katmanlar arasında güvenli ve net bir şekilde taşımaktır. DTOs ticari kuruluşların, modellerin veya hizmetlerin yerini alacak şekilde tasarlanmamıştır. Verileri öngörülebilir bir yapıda taşımak için tasarlanmıştır.

DTOs aşağıdakiler arasında veri aktarmak için kullanılabilir:

  • Denetleyiciler ve hizmetler.

  • Hizmetler ve depolar.

  • Commandlar ve komut işleyicileri.

  • Olaylar ve dinleyiciler.

  • Uygulama katmanları ve harici APIs.

  • Formlar ve uygulama kullanım durumları.

  • Etki alanı mantığı ve sunum katmanları.

Bu, veri akışının anlaşılmasını ve sürdürülmesini kolaylaştırır.

PHP'da Temel DTO Örneği

Aşağıdaki örnek, bir ürün oluşturmaya yönelik basit bir DTO'yu göstermektedir:

class CreateProductDto
{
    public function __construct(
        public string $name,
        public string $description,
        public float $price,
        public int $categoryId,
        public bool $isActive = true
    ) {
    }
}

Bu DTO, bir ürün oluşturmak için gereken tüm verileri tanımlar. Belirsiz bir diziyi iletmek yerine, uygulama güçlü bir şekilde yapılandırılmış bir nesneyi iletebilir.

Bir Hizmette DTO Kullanma

class ProductService
{
    public function create(CreateProductDto $dto): Product
    {
        return Product::create([
            'name' => $dto->name,
            'description' => $dto->description,
            'price' => $dto->price,
            'category_id' => $dto->categoryId,
            'is_active' => $dto->isActive,
        ]);
    }
}

Hizmet artık net bir veri nesnesine bağlı. Bu, okunabilirliği artırır ve yanlış dizi tuşlarının kullanılma olasılığını azaltır.

DTOs ve Tip Güvenliği

DTOs, özelliklerin açık türleri olabileceğinden tür güvenliğini artırır. Örneğin, fiyat float olarak,categorId int olarak ve isActive bool olarak tanımlanabilir.

Ham dizilerde yanlış değerler kolaylıkla aktarılabilir. Bir tam sayının beklendiği yerde bir dize iletilebilir veya gerekli bir anahtar eksik olabilir.

Yazılan DTOs, sorunların daha erken tespit edilmesine yardımcı olur ve IDE'lerde ve statik analiz araçlarında kodun anlaşılmasını kolaylaştırır.

PHP'da DTOs 8+

PHP 8, DTOs'nun yazılmasını kolaylaştıran yapıcı özelliği tanıtımını başlattı. Geliştiriciler, özellikleri tanımlamak ve manuel olarak atamak yerine bunları doğrudan yapıcıda tanımlayabilir.

class UpdateProfileDto
{
    public function __construct(
        public string $name,
        public ?string $phone,
        public ?string $city,
        public ?string $country
    ) {
    }
}

Bu sözdizimi DTO sınıfları için temiz ve pratiktir.

PHP'da salt okunur DTOs

Modern PHP'da DTOs, oluşturulduktan sonra yanlışlıkla yapılan değişiklikleri önlemek için salt okunur hale getirilebilir.

readonly class CreateOrderDto
{
    public function __construct(
        public int $userId,
        public array $items,
        public string $paymentMethod,
        public ?string $couponCode = null
    ) {
    }
}

Salt okunur bir DTO, verilerin oluşturulduktan sonra sabit kalması gerektiğinde kullanışlıdır. Bu, uygulama akışı sırasında beklenmedik değişiklikleri önleyebilir.

Dizilerden DTOs Oluşturma

Birçok uygulama verileri HTTP isteklerinden, formlardan, APIs veya JSON yüklerinden diziler halinde alır. DTO, kendisini bir diziden oluşturmak için statik bir fabrika yöntemi sağlayabilir.

class RegisterUserDto
{
    public function __construct(
        public string $name,
        public string $email,
        public string $password
    ) {
    }

    public static function fromArray(array $data): self
    {
        return new self(
            name: $data['name'],
            email: $data['email'],
            password: $data['password']
        );
    }
}

Bu, dizi eşlemesini tek bir yerde tutar ve hizmet kodunu daha temiz hale getirir.

Diziden DTO Kullanımı

$dto = RegisterUserDto::fromArray([
    'name' => 'Adnan Mehrat',
    'email' => 'adnan@example.com',
    'password' => 'secret',
]);

$user = $registrationService->register($dto);

Hizmet, ham dizi yerine yapılandırılmış bir DTO alır.

Laravel'da DTOs

Laravel geliştiricileri genellikle doğrulanmış istek verilerini diziler halinde hizmetlere iletir. Bu küçük projelerde yaygın ve kabul edilebilir bir durumdur. Ancak DTOs daha büyük uygulamalarda kodu daha net hale getirebilir.

Bir Laravel denetleyicisi, Form İsteğinden bir DTO oluşturabilir:

class RegisterController extends Controller
{
    public function store(
        RegisterUserRequest $request,
        UserRegistrationService $service
    ) {
        $dto = RegisterUserDto::fromArray($request->validated());

        $user = $service->register($dto);

        return response()->json($user);
    }
}

Form İsteği validation'yu işler ve DTO doğrulanmış verileri hizmet katmanına taşır.

DTO ile Laravel Formu İsteği

Yararlı bir yaklaşım, Form İsteğinin içine DTO döndüren bir yöntem eklemektir:

class RegisterUserRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'name' => ['required', 'string'],
            'email' => ['required', 'email'],
            'password' => ['required', 'min:8'],
        ];
    }

    public function toDto(): RegisterUserDto
    {
        return RegisterUserDto::fromArray($this->validated());
    }
}

Denetleyici daha temiz hale gelir:

$user = $service->register($request->toDto());

Bu, validation ve DTO oluşturma işlemini istek katmanına yakın tutarken hizmeti HTTP ayrıntılarından bağımsız tutar.

Symfony'da DTOs

Symfony uygulamaları DTOs'yu formlar, denetleyiciler, istek yükleri, Messenger komutları, API Platformu ve hizmet katmanlarıyla kullanabilir.

Örneğin, bir denetleyici istek verilerinden bir DTO oluşturabilir ve bunu bir hizmete iletebilir:

class RegisterController
{
    public function __invoke(Request $request, UserRegistrationService $service): Response
    {
        $dto = new RegisterUserDto(
            name: $request->request->get('name'),
            email: $request->request->get('email'),
            password: $request->request->get('password')
        );

        $user = $service->register($dto);

        return new JsonResponse(['id' => $user->getId()]);
    }
}

DTOs, komutlar verileri işleyicilere taşıdığında Symfony Messenger'da da kullanışlıdır.

DTO Modeli ve APIs

DTOs, API geliştirmede çok faydalıdır. APIs sıklıkla istek verilerini alır ve yanıt verilerini döndürür. DTOs hem girişi hem de çıkışı yapılandırabilir.

Giriş için DTO, bir kaynağı oluşturmak veya güncellemek için gereken verileri temsil edebilir. Çıkış için DTO, istemciye döndürülmesi gereken yanıt biçimini temsil edebilir.

Bu, uygulamanın dahili database modellerini doğrudan API aracılığıyla açığa çıkarmasını önler.

Yanıt DTO Örneği

DTO yanıtı, istemciye hangi verilerin döndürülmesi gerektiğini tanımlayabilir:

class UserResponseDto
{
    public function __construct(
        public int $id,
        public string $name,
        public string $email
    ) {
    }

    public static function fromUser(User $user): self
    {
        return new self(
            id: $user->id,
            name: $user->name,
            email: $user->email
        );
    }

    public function toArray(): array
    {
        return [
            'id' => $this->id,
            'name' => $this->name,
            'email' => $this->email,
        ];
    }
}

API, tam Kullanıcı modelini ortaya çıkarmak yerine yalnızca DTO'da tanımlanan alanları döndürebilir.

DTO Modeli ve Harici APIs

DTOs, harici APIs ile entegre edilirken kullanışlıdır. Harici APIs genellikle verileri dahili uygulama yapısıyla eşleşmeyen formatlarda döndürür.

Bir adaptör, harici yanıt verilerini dahili bir DTO'ya dönüştürebilir. Uygulamanın geri kalanı daha sonra kararlı bir yapıyla çalışabilir.

class PaymentResultDto
{
    public function __construct(
        public bool $successful,
        public string $transactionId,
        public ?string $errorMessage = null
    ) {
    }
}

Bir ödeme bağdaştırıcısı, ham sağlayıcıya özgü dizileri döndürmek yerine PaymentResultDto değerini döndürebilir.

DTO Modeli ve Adapter Pattern

DTO Deseni, Adapter Pattern ile iyi çalışır. Bir adaptör uyumsuz sistemleri birbirine bağlar ve DTO, uygulama tarafından kullanılan dahili veri formatını tanımlayabilir.

Örneğin Stripe ve PayPal farklı yanıt yapıları döndürebilir. Her bağdaştırıcı, sağlayıcının yanıtını aynı PaymentResultDto'ya dönüştürebilir. Uygulama daha sonra ödeme sonuçlarını tutarlı bir şekilde işler.

Bu, sağlayıcıya özel ayrıntıları izole eder ve entegrasyonların sürdürülmesini kolaylaştırır.

DTO Modeli ve Service Layer

DTOs, Service Layer Modeli ile yaygın olarak kullanılır. Denetleyiciler istekleri alır ve DTOs'yu oluşturur. Hizmetler DTOs'yu alır ve business logicnı yürütür.

Bu, hizmetleri HTTP istek nesnelerinden bağımsız tutar ve denetleyiciler, konsol komutları, işler ve testler gibi farklı giriş noktalarından yeniden kullanılabilir olmalarını sağlar.

Örneğin, aynı CreateProductDto bir yönetici paneli denetleyicisi, bir API denetleyicisi veya bir içe aktarma komutu tarafından kullanılabilir.

DTO Modeli ve Command Pattern

DTOs ve komutlar benzer görünebilir. Her ikisi de veri taşıyabilir. Ancak onların niyeti farklıdır.

DTO, verileri katmanlar arasında taşır. Command, yürütülmesi gereken bir eylemi temsil eder.

Örneğin, RegisterUserDto kullanıcı kayıt verilerini açıklar. RegisterUserCommand, bir kullanıcıyı kaydetme isteğini temsil edebilir ve bir komut işleyicisi tarafından işlenebilir.

Bazı mimarilerde komut nesneleri, kullanım durumları için DTOs gibi davranır. Adlandırma tasarım stiline bağlıdır.

DTO ve Model

DTO bir modelle aynı değildir. Bir model genellikle bir etki alanı kavramını veya database varlığını temsil eder. İlişkileri, kalıcılık mantığını, etki alanı davranışını, erişimcileri, değiştiricileri veya ORM özelliklerini içerebilir.

DTO esas olarak veri aktarımı için kullanılır. Bir kullanım senaryosuna göre daha basit ve daha spesifik olmalıdır.

Örneğin, bir Kullanıcı modeli kimlik, ad, e-posta, şifre, roller, izinler, zaman damgaları, ilişkiler ve yöntemleri içerebilir. RegisterUserDto yalnızca adı, e-postayı ve parolayı içerebilir.

DTO ve Dizi

Diziler esnektir ancak yapıyı açıkça tanımlamazlar. Bir dizi alan yöntem, hangi anahtarların gerekli olduğunu veya hangi türlerin beklendiğini göstermez.

DTOs, adlandırılmış özellikler ve türlerle net bir yapı sağlar. Okunabilirliği, IDE desteğini, statik analizi ve sürdürülebilirliği geliştirirler.

Küçük ve basit işlemler için diziler yeterli olabilir. Daha büyük iş akışları ve önemli veri aktarımı için DTOs genellikle daha nettir.

DTO ve Değer Nesnesi

DTO ve Değer Nesnesi farklı kavramlardır. DTO, verileri katmanlar arasında aktarır. Değer Nesnesi, etki alanındaki anlamlı bir değeri temsil eder ve genellikle validation veya davranışı içerir.

Örneğin, EmailAddress geçerli bir e-postayı temsil ettiğinden ve biçimini doğrulayabildiğinden bir Değer Nesnesi olabilir. RegisterUserDto, kullanıcı kayıt verilerinin bir parçası olarak bir e-posta dizesi veya bir EmailAddress nesnesi içerebilir.

Değer Nesneleri alan anlamını ifade eder. DTOs hızlı veri aktarım yapısını ifade eder.

DTO vs Varlık

Bir varlığın kimliği vardır ve genellikle zamanla değişen bir nesneyi temsil eder. Örneğin Kullanıcı, Sipariş, Ürün ve Fatura varlıklar olabilir.

DTO genellikle kimlik veya yaşam döngüsü davranışına sahip değildir. Basitçe belirli bir işlem veya yanıta ilişkin verileri taşır.

Varlıkların her yerden geçmesi çok fazla iç yapıyı ortaya çıkarabilir. DTOs, uygulamanın yalnızca belirli bir amaç için gereken verileri iletmesine izin verir.

DTO Doğrulaması

DTOs'nun verileri doğrulaması gerekip gerekmediği konusunda farklı görüşler var. Birçok uygulamada, validation, Laravel Form İsteği veya Symfony Doğrulayıcı gibi DTO oluşturulmadan önce işlenir.

Ancak DTOs yine de kurucu türleri aracılığıyla temel tür güvenliğini zorunlu kılabilir. Bazı projeler ayrıca DTO fabrika yöntemlerinin içine basit validation ekler.

Önemli olan DTOs'yu büyük business logic sınıflarına dönüştürmekten kaçınmaktır. Karmaşık validation ve iş kuralları genellikle doğrulayıcılara, hizmetlere, etki alanı nesnelerine veya değer nesnelerine aittir.

Değişmez DTOs

DTOs genellikle değişmez olacak şekilde tasarlanmıştır. Bu, değerlerinin yaratıldıktan sonra değişmediği anlamına gelir.

Değiştirilemez DTOs, veri akışını daha öngörülebilir hale getirir. Doğrulanmış girişten bir DTO oluşturulduktan sonra uygulamanın diğer bölümleri onu yanlışlıkla değiştiremez.

PHP'da salt okunur sınıflar ve salt okunur özellikler, değişmez DTOs oluşturulmasına yardımcı olabilir.

readonly class UpdateEmailDto
{
    public function __construct(
        public int $userId,
        public string $newEmail
    ) {
    }
}

Bu veri aktarımı için temiz ve güvenli bir yapıdır.

Yuvalanmış DTOs

Bazı veri yapıları iç içe geçmiş veriler içerir. Örneğin bir sipariş, müşteri verilerini ve sipariş öğelerini içerebilir. DTOs bu yapıyı net bir şekilde temsil edecek şekilde iç içe yerleştirilebilir.

readonly class OrderItemDto
{
    public function __construct(
        public int $productId,
        public int $quantity,
        public float $price
    ) {
    }
}

readonly class CreateOrderDto
{
    public function __construct(
        public int $userId,
        public array $items,
        public string $paymentMethod
    ) {
    }
}

Daha katı bir uygulamada, items dizisi yalnızca OrderItemDto nesnelerini içermelidir. Bu yapıyı net tutar.

DTO Koleksiyonları

DTOs listeleriyle çalışırken bazı projeler DTO collection sınıfları oluşturur. DTO collection, bir listenin yalnızca belirli DTO nesnelerini içermesini sağlar.

class OrderItemDtoCollection
{
    private array $items = [];

    public function add(OrderItemDto $item): void
    {
        $this->items[] = $item;
    }

    public function all(): array
    {
        return $this->items;
    }
}

Bu, collection’ın kuralları olduğunda veya daha güçlü bir yapıya ihtiyaç duyulduğunda kullanışlıdır. Basit durumlar için bir DTOs dizisi yeterli olabilir.

DTO Eşleme

DTO eşlemesi, verileri bir yapıdan DTO'ya dönüştürme işlemidir. Bu, dizilerden, isteklerden, modellerden, varlıklardan veya harici API yanıtlarından eşlemeyi içerebilir.

Eşleme, statik fabrika yöntemleri, eşleyici sınıfları, transformatörler veya çerçeveye özgü kaynaklar içinde yapılabilir.

Küçük DTOs için fromArray veya fromModel yöntemi genellikle yeterlidir. Karmaşık eşleme için özel bir eşleyici sınıfı daha temiz olabilir.

Eşleyici Sınıfı Örneği

class UserDtoMapper
{
    public function fromUser(User $user): UserResponseDto
    {
        return new UserResponseDto(
            id: $user->id,
            name: $user->name,
            email: $user->email
        );
    }
}

Bir eşleyici, DTO oluşturma karmaşık hale geldiğinde dönüşüm mantığını ayrı tutabilir.

DTOs ve API Kaynakları

Laravel'da, API Kaynakları genellikle modelleri JSON yanıtlarına dönüştürmek için kullanılır. API Kaynaklar bazen DTOs yanıtı ihtiyacını azaltabilir.

Ancak DTOs, giriş verileri, hizmet katmanı veri aktarımı, komut verileri, harici API entegrasyonu ve çerçeveden bağımsız mimari için hâlâ kullanışlıdır.

DTOs ve API Kaynakları arasındaki seçim amaca bağlıdır. API Kaynaklar sunum odaklıdır, DTOs ise genel veri aktarım nesneleridir.

DTO Modeli'nin Faydaları

DTO Modeli, nesne yönelimli yazılım tasarımında birçok fayda sağlar.

Ana faydalar şunları içerir:

  • Veri aktarımını açık ve yapılandırılmış hale getirir.

  • Ham dizilere olan bağımlılığı azaltır.

  • Okunabilirliği ve yazım güvenliğini artırır.

  • Dahili modellerin her yerde açığa çıkmasını önler.

  • IDE desteğini ve statik analizi geliştirir.

  • Servis yöntemlerini daha net hale getirir.

  • APIs, hizmetler, komutlar ve harici entegrasyonlarla iyi çalışır.

  • clean architecture'yu ve endişelerin ayrılmasını destekler.

Bu avantajlar DTOs'yu özellikle orta ve büyük uygulamalarda kullanışlı kılmaktadır.

DTO Deseninin Dezavantajları

DTO Modeli'nin dezavantajları da olabilir. Projeye çok basit özellikler için gereksiz olabilecek daha fazla sınıf ekler.

Diğer bir dezavantaj ise haritalamanın ek yük olmasıdır. Geliştiricilerin dizileri, modelleri veya API yanıtlarını DTOs'ya dönüştürmesi gerekir. Aşırı kullanılırsa tekrarlanan kodlar oluşabilir.

DTOs ayrıca açıkça adlandırılmazsa veya yanlış amaç için kullanılırsa kafa karıştırıcı olabilir. DTO, her yerde kullanılan genel bir nesne haline gelmemeli, belirli bir veri aktarım ihtiyacını temsil etmelidir.

DTO Deseni Ne Zaman Kullanılır?

Veriler katmanlar arasında hareket ederken net bir yapıya ihtiyaç duyduğunda DTO Desenini kullanın.

DTO Modeli şu durumlarda kullanışlıdır:

  • Bir hizmet birçok giriş değeri alır.

  • Ham diziler belirsiz veya riskli hale geliyor.

  • Aynı veri yapısı birden fazla katmandan geçirilir.

  • Modelleri doğrudan maruz kalmaktan korumak istiyorsunuz.

  • APIs'yu net istek veya yanıt formatlarıyla oluşturuyorsunuz.

  • Harici APIs ile entegrasyon yapıyorsunuz.

  • Daha iyi tür güvenliği ve IDE desteği istiyorsunuz.

  • Proje clean architecture veya hizmet katmanı tasarımını kullanıyor.

Bu koşullar mevcutsa DTOs tasarımı daha temiz ve daha güvenli hale getirebilir.

DTO Deseni Ne Zaman Kullanılmamalı?

DTOs'yu her küçük işlem için otomatik olarak kullanmayın. Bir özellik basitse ve veri yapısı açıksa DTO gereksiz karmaşıklık katabilir.

Aşağıdaki durumlarda DTOs'dan kaçının:

  • İşlemin yalnızca bir veya iki basit değeri vardır.

  • DTO yalnızca bir modeli amaçsızca kopyalayacaktır.

  • Proje çok küçük ve basitlik daha önemli.

  • Eşleme kodu, sorunun kendisinden daha karmaşık hale gelir.

  • DTO, sorumluluğu belirsiz olan genel bir nesne olarak kullanılır.

DTOs netliği artırmalıdır. Yalnızca kodun daha gelişmiş görünmesi için eklenmemelidirler.

DTO Deseniyle İlgili Yaygın Hatalar

Yaygın hatalardan biri DTOs'ya business logic eklemektir. Bir DTO, karmaşık iş akışlarını yürütmemeli, veri taşımalıdır.

Diğer bir hata ise çok genel olan DTOs oluşturmaktır. Örneğin, UserDto'nun kayıt, profil güncellemeleri, API yanıtları, yönetici görünümleri ve harici entegrasyonlar için kullanılıp kullanılmadığı belirsiz hale gelebilir. RegisterUserDto veya UserResponseDto gibi belirli DTOs genellikle daha açıktır.

Üçüncü bir hata, maruz kalmayı azaltmadan veya yapıyı iyileştirmeden modellerin kopyalanmasıdır. Bir DTO'nun varolmak için bir nedeni olmalıdır.

Dördüncü hata, daha güçlü bir yapıya ihtiyaç duyulduğunda ham dizilerin DTOs içinde net bir yazım olmadan geçirilmesidir. İç içe DTOs karmaşık veriler için daha iyi olabilir.

DTO Modeli için En İyi Uygulamalar

DTO Desenini etkili bir şekilde kullanmak için geliştiricilerin DTOs'yu basit, odaklanmış ve anlamlı tutması gerekir.

Yararlı en iyi uygulamalar şunları içerir:

  • Belirli kullanım durumları için DTOs oluşturun.

  • CreateOrderDto veya UserResponseDto gibi anlaşılır adlar kullanın.

  • Yazılan özellikleri tercih edin.

  • Verilerin değişmemesi gerektiğinde salt okunur DTOs kullanın.

  • DTOs içindeki karmaşık business logicndan kaçının.

  • Yararlı olduğunda fromArray gibi fabrika yöntemlerini kullanın.

  • Karmaşık dönüşümler için eşleyici sınıflarını kullanın.

  • DTOs yanıtına göre hassas model alanlarını göstermeyin.

  • Açık bir amaç olmadan DTOs oluşturmaktan kaçının.

Bu uygulamalar DTOs'nun kullanışlı ve bakımı kolay kalmasına yardımcı olur.

DTO Oluşturmadan Önce Pratik Kontrol Listesi

DTO oluşturmadan önce geliştiriciler şu soruları sorabilir:

  • Ham dizi verileri belirsizleşiyor mu?

  • Bu işlemin net bir giriş veya çıkış yapısına ihtiyacı var mı?

  • Bu DTO dahili modelleri maruziyete karşı koruyacak mı?

  • Yazılan özellikler güvenliği artıracak mı?

  • DTO tek bir kullanım senaryosuna özel mi?

  • DTO servis yönteminin anlaşılmasını kolaylaştıracak mı?

  • Haritalama çabası kazanılan netliğe değer mi?

Bu soruların birçoğunun cevabı evet ise DTO iyi bir tasarım tercihi olabilir.

DTO Deseni Yeni Başlayanlar İçin Neden Önemlidir?

Yeni başlayanlar için DTOs ilk başta ekstra dersler gibi görünebilir. Ancak uygulamalar büyüdüğünde ve veriler birçok katman arasında hareket etmeye başladığında çok kullanışlı hale gelirler.

DTOs'yu öğrenmek, yeni başlayanların temiz veri akışını, hizmet katmanı tasarımını, API yanıt kontrolünü, harici entegrasyon eşlemesini ve tür açısından güvenli uygulama kodunu anlamasına yardımcı olur.

DTOs ayrıca geliştiricilerin business logic içindeki ham dizilere ve çerçeveye özgü istek nesnelerine çok fazla güvenmekten uzaklaşmasına da yardımcı olur.

Sonuç

DTO Modeli, yapılandırılmış verileri uygulama katmanları arasında aktarmak için kullanılan bir yazılım tasarım modelidir. DTO, net veri alanlarını tanımlar ve net olmayan ham dizilerden, aşırı pozlanmış modellerden ve sıkı bir şekilde birleştirilmiş istek işlemeden kaçınmaya yardımcı olur.

DTOs, PHP, Laravel, Symfony, APIs, hizmet katmanları, komut işleyicileri, harici entegrasyonlar ve clean architecture'da faydalıdır. Okunabilirliği, tür güvenliğini, sürdürülebilirliği ve endişelerin ayrılmasını geliştirirler.

Ancak DTOs dikkatli kullanılmalıdır. Basit işlemler DTOs'ya ihtiyaç duymayabilir ve DTOs business logic sınıfları haline gelmemelidir. Doğru uygulandığında DTO Modeli temiz, düzenli ve ölçeklenebilir nesne yönelimli yazılım oluşturmaya yönelik pratik bir araçtır.