DTO Nedir? Spring Boot'ta Entity vs DTO Farkı (2026)

1. DTO Nedir? Ne Demek?

DTO (Data Transfer Object), uygulamanın dış sistemlerle —örneğin bir mobil uygulama veya web arayüzü ile— veri alışverişi yaparken kullandığı, iş mantığı (business logic) içermeyen ve yalnızca veriyi taşıyan basit nesnelerdir. İlk kez Martin Fowler tarafından tanımlanan bu tasarım örüntüsü, Java dünyasında fiili bir standarttır.

Temel Kural: Entity veritabanının dilidir, DTO ise API'nin dilidir. Veritabanı yapısını doğrudan API üzerinden dışarı yansıtmak büyük bir mimari hatadır.

2. Neden DTO Kullanılır? Ne İşe Yarar?

Veritabanından çektiğiniz bir Entity sınıfını doğrudan API yanıtı olarak (örneğin JSON olarak) döndürmek kısa vadede kolay görünse de, production (canlı) ortamında ciddi sorunlara yol açar. DTO kullanmanın üç temel sebebi vardır:

1) Maksimum Güvenlik

Entity sınıfları genellikle password, TCKN, internalStatus, veya createdAt gibi kullanıcının asla görmemesi gereken hassas alanlar içerir. DTO kullandığınızda, yalnızca açıkça tanımladığınız alanlar API'den çıkar. Böylece hassas veri sızıntısı (Data Leak) kesin olarak önlenir.

2) API Sözleşmesi ve Stabilite

Veritabanı şemasında bir tablonun adı veya kolon yapısı değiştiğinde Entity sınıfı da değişmek zorundadır. Eğer Entity'yi doğrudan API'de kullanıyorsanız, bu değişiklik mobil uygulamanızı veya frontend'inizi anında çökertir (kırar). DTO ise bir API sözleşmesidir. Veritabanı değişse bile DTO sabit kalacağı için sistemler arası uyum bozulmaz.

3) Performans ve Hız

Entity, tablondaki tüm kolonları içerir. Oysa istemcinin (client) sadece kullanıcının adına ve e-postasına ihtiyacı olabilir. Sadece gerekli alanları içeren bir DTO göndermek JSON boyutunu (payload) küçültür, bant genişliği tasarrufu sağlar ve API yanıt süresini gözle görülür biçimde hızlandırır.

3. Entity vs DTO Farkı Nedir?

Entity ve DTO'nun sorumluluklarını birbirine karıştırmak en yaygın hatalardan biridir. Aşağıdaki tablo bu iki kavram arasındaki temel farkları özetler:

4. Spring Boot DTO Kod Örneği

Aşağıda tipik bir Müşteri (Customer) Entity'si ve bu veriyi dış dünyaya güvenle açtığımız bir DTO örneği yer almaktadır:

Entity (Veritabanı Modeli):

@Entity
@Table(name = "customers")
public class Customer {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    private String firstname;
    private String lastname;
    private String email;
    
    private String password;         // API'ye ASLA açılmamalı!
    private LocalDateTime createdAt; // API'ye ASLA açılmamalı!
}

DTO (API Sözleşmesi):

public class CustomerDto {
    private Long id;
    private String firstname;
    private String lastname;
    private String email;
    
    // Dikkat: password ve createdAt alanları burada bilerek yoktur.
}

5. MapStruct ile Entity → DTO Dönüşümü

Entity sınıfındaki verileri DTO'ya aktarmak için dto.setAd(entity.getAd()) şeklinde manuel kod yazmak büyük projelerde işkenceye dönüşür. MapStruct, bu dönüşümü derleme zamanında (compile-time) otomatik olarak yapan harika bir kütüphanedir. ModelMapper gibi kütüphanelerin aksine Reflection kullanmadığı için performansı çok daha yüksektir.

pom.xml Bağımlılığı:

<dependency>
    <groupId>org.mapstruct</groupId>
    <artifactId>mapstruct</artifactId>
    <version>1.5.5.Final</version>
</dependency>

Mapper Arayüzü:

@Mapper(componentModel = "spring")
public interface CustomerMapper {
    CustomerDto toDto(Customer customer);
    Customer toEntity(CustomerDto dto);
    List<CustomerDto> toDtoList(List<Customer> customers);
}

Service Katmanında Kullanımı:

@Service
@RequiredArgsConstructor
public class CustomerService {
    private final CustomerRepository repository;
    private final CustomerMapper mapper;

    public CustomerDto getById(Long id) {
        Customer customer = repository.findById(id)
            .orElseThrow(() -> new RuntimeException("Müşteri bulunamadı"));
            
        // Entity'yi doğrudan dönmüyoruz, Mapper ile DTO'ya çeviriyoruz!
        return mapper.toDto(customer);
    }
}

6. Request DTO vs Response DTO Mantığı

Gerçek dünya projelerinde, istemciden gelen veriyi almak (Request) ve istemciye veri göndermek (Response) için aynı DTO sınıfını kullanmak iyi bir fikir değildir. Bunları ayırmak, doğrulama (validation) kurallarınızı çok daha temiz yönetmenizi sağlar.

Request DTO (Gelen veriyi doğrular):

public class CreateCustomerRequest {
    @NotBlank(message = "Ad alanı boş bırakılamaz")
    private String firstname;

    @NotBlank(message = "Soyad alanı boş bırakılamaz")
    private String lastname;

    @Email(message = "Geçerli bir e-posta adresi giriniz")
    @NotBlank
    private String email;

    @Size(min = 8, message = "Şifre en az 8 karakter olmalıdır")
    private String password;
}

Response DTO (Dış dünyaya açılan alanlar):

public class CustomerResponse {
    private Long id;
    private String firstname;
    private String lastname;
    private String email;
    // Güvenlik gereği password alanı burada tanımlanmamıştır.
}

Controller Katmanı Entegrasyonu:

@PostMapping("/customers")
public ResponseEntity<CustomerResponse> create(
        @RequestBody @Valid CreateCustomerRequest request) {
        
    CustomerResponse response = customerService.create(request);
    return ResponseEntity.status(HttpStatus.CREATED).body(response);
}

7. Java Record ile DTO Oluşturma (Java 17+)

Java 16 ile dile eklenen record yapısı, immutable (değiştirilemez) DTO'lar oluşturmanın en modern ve en kısa yoludur. Boilerplate kod yazmanıza (Getter, Setter, toString) gerek bırakmaz:

public record CustomerDto(
    Long id,
    String firstname,
    String lastname,
    String email
) {}

Record'lar doğası gereği değiştirilemez olduğu için thread-safe bir yapı sunar ve verilerin uygulama içinde yanlışlıkla değiştirilmesini imkansız kılar. Spring Boot 3.x versiyonlarında JSON serileştirme işlemleri için tam uyumludur.

8. DTO Best Practices (2026 Standartları)

• Entity'leri asla API'den dışarı sızdırmayın: Controller metodları her zaman DTO dönmeli ve dışarıdan DTO kabul etmelidir.
• Request ve Response DTO'larını mutlaka ayırın: Sistem büyüdükçe giriş ve çıkış parametreleri birbirinden farklılaşır.
• Validasyonları Request DTO'da yapın: @NotNull, @Email gibi anotasyonların yeri Entity değil, doğrudan dışarıdan gelen Request DTO'sudur.
• MapStruct tercih edin: Performans sorunları yaratabilen ModelMapper yerine compile-time çalışan MapStruct kullanın.
• Salt-okunur (read-only) veriler için Record kullanın: Eğer projeniz Java 17 ve üzeri ise, Response DTO'larınızı Java record yapısıyla oluşturun.

Sonuç

Spring Boot uygulamalarında DTO örüntüsünü (Design Pattern) kullanmak, projelerinizi güvenli, sürdürülebilir ve esnek hale getirir. Entity'leri doğrudan dışarıya açmak başlangıçta kod yazma süresini kısaltsa da, uzun vadede baş ağrıtıcı bakım sorunlarına neden olur.

Projelerinizde MapStruct ile otomatik dönüşümleri kurgulayıp, Java record yapılarını devreye alarak 2026 standartlarında temiz ve profesyonel bir mimari inşa edebilirsiniz.

İlgili diğer yazılarımız:

• JPA ve JDBC Nedir? Farkları ve Kullanımı
• Spring @Autowired Nedir? Dependency Injection
• Veritabanı Transaction ve ACID Kuralları Nelerdir?