DTO’lar (Data Transfer Object), bazı geliştiriciler tarafından açıklanırken çok basit bir şekilde ele alınabiliyor, bu da konuyu anlaşılır kılıyor ancak derinlemesine bir anlayış kazandırmıyor. Bu makalede DTO’ların kullanımına dair avantajları ve pratik örnekler sunulacaktır.
Birçok kişi şu soruları sorar:
- DTO’ları neden kullanmalıyım?
- Normal yöntemlerle yapamaz mıyım? Bu aşırı mühendislik değil mi?
Aşağıdaki örnekte bir DTO oluşturma sürecine bakalım:
namespace App\DTO;
class UserDTO
{
public string $name;
public string $email;
public string $password;
public function __construct(string $name, string $email, string $password)
{
$this->name = $name;
$this->email = $email;
$this->password = $password;
}
}
DTO’yu kullanmak için bir örnek:
public function createUser(Request $request)
{
$userDTO = new UserDTO(
$request->input('name'),
$request->input('email'),
$request->input('password')
);
$user = $this->userService->createUser($userDTO);
return response()->json($user);
}
Ancak biri şöyle diyebilir: DTO kullanmak zorunda mıyım? Bunun yerine şunu yapabilirim:
$user = $this->userService->createUser($request->all()); // $request->validate()
Bu noktada $fillable ile kitle atama korumam vardır.
Doğru: Haklısınız.
Gerçek Dünya Örneği: Büyük Veriler ve Katmanlar
Büyük verilerle çalıştığımızda ve verileri çeşitli katmanlardan ilettiğimizde genellikle diziler kullanırız. Aşağıdaki $history yapısına bir göz atalım:
Aynı yapıyı kullanıyorum:
HolidayShiftPublicHolidayErrandsLeavesOvertimeRequest
Bu yapılarda bazı öğeler 0, null veya hiç var olmayabilir.
public function getHolidayHistory($timeManagement, $overtime_schedule, $contract, $work_schedule, $publicHolidays, $attend)
{
$holiday = [];
foreach ($publicHolidays as $holiday) {
if (Carbon::parse($attend->date)->between($holiday->start_date, $holiday->end_date)) {
$latesSignInMinutes = $this->calculator->calculateLateSignIn($attend, $work_schedule->start_time);
$earlyLeaving = $this->calculator->calculateEarlyLeaving($attend, $work_schedule->end_time);
$history[] = [
'absent' => false,
'type' => 'holiday',
'date' => $attend->date,
'item' => $holiday,
'attend_item' => $attend,
'data' => [
'sign_in' => $attend->sign_in,
'sign_out' => $attend->sign_out,
'late' => $latesSignInMinutes,
'late_deducted_percent' => 0,
'early_leaving_deducted_percent' => 0,
'early_leaving' => $this->calculator->checkFromFingerprintOut($timeManagement, $earlyLeaving),
'deducted_percent' => 0,
'overtime' => Carbon::parse($attend->duration)->hour,
'amount_overtime' => $this->presentPublicHolidays->getPresentPublicHolidayAmount(
$overtime_schedule,
$contract,
$attend->duration
),
],
];
}
}
$history[] = [
=> true,
=> ,
=> $attend->date,
=> $attend,
];
return $history;
}
Peki burada potansiyel problemler görebiliyor musunuz? Kodlama açısından, hata almadan çalışabiliriz ancak gerçek dünyada her zaman %100 güvenilir değiliz.
Büyük özellikler için test kullanımını benimsiyoruz; ancak bu gibi durumlarda TDD her zaman uygulanabilir olmayabiliyor. Dolayısıyla, bazı öğeler yoksa her kullanımda $history için her seferinde yazmamız gereken kod:
isset($history[]) ? $history[] : 0; // or
$history[] ?? 0;
DTO’lar Burada Kullanılabilir Mi?
$history[] = new AttendanceHistoryDTO(
absent: false,
type: ,
date: $attend->date,
item: $holiday,
attend_item: $attend,
data: new AttendanceDataDTO(
: $attend->sign_in,
: $attend->sign_out,
: $latesSignInMinutes,
: $this->->(, ),
: 0,
: Carbon::($attend->duration)->hour,
: $this->presentPublicHolidays->(
$overtime_schedule,
$contract,
$attend->duration
),
: 0,
: 0,
)
Artık $history‘yi kullanırken endişelenmemize gerek yok:
isset($history[]) ? $history[] : 0;
Çünkü varsayılan değerler artık DTO’nun içinde saklı.
Gerçek Kullanımda Eksik Verilerin İşlenmesi
Aşağıda gerçek kullanım örneği:
isset($content?->data?->total_late) ? $content?->data?->total_late : 0;
Neden hala bunu yapıyorum?
DTO’lar kullanıldığında:
- Varlık olmayan bir şey yazarsanız, editörünüz sizi uyarır.
- PHP, geliştirme ve test sürecinde bir istisna fırlatır — bu iyi bir durumdur.
- Ancak üretimde istisnalara sahip olmak her zaman iyi bir fikir değildir. 😅
Doğru Yaklaşım: İş İhtiyaçlarına Odaklanmak
DTO’ları kullanmanın birçok doğru yolu vardır. Ancak her zaman öncelikle iş ihtiyaçlarına odaklanmalısınız. Problemi anlamak, ardından doğru aracı seçmek gerekir.
Kişisel olarak, tercih ettiğim yöntem:
Kodu kötü yaz → normal hale getir → sonra en iyi çözüm nedir diye sor.
Sizce bu konuda ne düşünüyorsunuz? 😃
Kaynak: Orijinal Makale
