Erdinç Yaşan

.NET'te Dependency Injection Nedir, Neden Kullanılır

2026-09-05T00:00:00+00:00

Herkese selam, bu yazımda ASP.NET'in kalbinin atmasını sağlayan ve diğer framework'lerden öne çıkmasını sağlayan, built-in gelen bir yapıdan bahsetmek istiyorum. Dependency Injection. Bu arkadaşın ismi Türkçede pek anlamlı değil, o yüzden ne olduğunu bilsek ve nasıl çalıştığını anlasak yeterli. İsminin Türkçe karşılığı bağımlılık enjeksiyonu (aslında fena da değil).</p>

Konuya deep dive yapmadan önce bu ihtiyacı ortaya çıkarsak daha iyi olacak sanırım.</p>

(Buradaki örneği bilerek çok absürt tutuyorum ki ilgili yazıyı söve söve okumaya devam edelim.)</p>

Başlamadan önce</h2>
Bu yazıyı takip etmek için temel seviyede C# bilgisi yeterli: class, constructor, method ve interface kavramlarına aşina olmanız gerekiyor. Örnekleri kendiniz çalıştırmak isterseniz .NET 10 SDK kurulu olsun, veritabanı ya da başka bir kurulum gerekmiyor.</p>

DI olmasaydı ne yazardık?</h2>

Yazmış olduğumuz kodda veriyi bir dosyada tuttuğumuzu düşünelim. Elimizde bir dosya yolu var, örneğin ne olsun, data/users.csv</code> bu şekilde bir yolumuz olsun.</p>

Örnek bağlamında tablolar ekleyeceğim, bu tabloları da olabildiğince basic tutarak ilerliyorum, her tablo bir CSV dosyası olsun. Örneğin users</code> adlı tablomuz var, iki tane de işlemimiz olacak: kullanıcı kayıt ve kullanıcı okuma senaryosu. Diyelim ki yeni başladık ve functional programming'den geldik. Hemen açtık iki tane fonksiyon, kayıt ol ve kullanıcı oku diye. Her iki fonksiyonun başlangıcında da kullanıcıyı dosyaya kaydetmek için ve kullanıcıyı dosyadan okumak için dosya yolunu tekrar tekrar yazacağız.</p>

Örnek olarak verdiğim uygulamada kullanıcıları saklamak için şöyle bir method yazdım:</p>

_01_WhereItComes/Program.cs</a>where-it-comes-01</a></div>
50</span>void</span> RegisterUser</span>(</span>string</span> email</span>,</span> string</span> displayName</span>)</span></span>
51</span>{</span></span>
52</span>    Directory</span>.</span>CreateDirectory</span>(</span>"</span>data</span>"</span>)</span>;</span></span>
53</span></span>
54</span>    File</span>.</span>AppendAllText</span>(</span>"</span>data/users.csv</span>"</span>,</span> $"</span>{</span>email</span>}</span>,</span>{</span>displayName</span>}</span>{</span>Environment</span>.</span>NewLine</span>}</span>"</span>)</span>;</span></span>
55</span>}</span></span></code></pre>



Credential'ları repoda saklamak: SOPS + age
2026-08-14T00:00:00+00:00
Projelerimden birinde deployment aşamasında takıldığım bir soru vardı: secret
değerlerini nerede tutmam gerekiyor? Başlarda bunları GitHub üzerinde secret
olarak saklıyordum. Çalışıyordu çalışmasına ama zamanla tekrar okuması beni
zorladı.</p>
İlk yöntemim tüm .env</code> dosyasını tek bir GitHub secret'inin içine koymaktı.
Kolaydı, ama bu sefer hangi secret'in set edilmiş olduğunu göremiyordum: her şey
tek bir blok. Bunun yerine her değeri ayrı secret yapmaya kalksam bu sefer de
secret sayısı arttıkça onlarca değeri tek tek set etmem gerekiyordu, yönetmesi
ayrı dert.</p>
Sunucuda doğrudan bir secret dosyası da tutabilirdim. Ama o zaman da her
değişiklik için sunucuya bağlanmam gerekecekti. İstediğim şeyi netleştirdim: CI
sürecini hiç bozmadan, secret'i otomatik değiştirip deploy edebilmek.</p>
Biraz araştırınca Mozilla ekibinin çıkardığı bir yöntem karşıma çıktı: SOPS. age
ile birleştirince secret'ları şifreli halde reponun içinde tutabiliyordum. Kod
nerede, secret de orada olsun, ama düz metin olarak değil. Bu yazıda bunu nasıl
yaptığımı, nerede işe yaradığını ve nerede dikkat etmek gerektiğini anlatıyorum.</p>
Bütün örnekler çalışan bir demo repoda:
https://github.com/erdyasan/sops-age-example</p>
Fikir</h2>
İki parça var:</p>

age</strong>: basit, modern bir şifreleme aracı. Bir public/private key çifti
üretiyoruz. Public key ile şifrelenen şeyi yalnızca private key açıyor.</li>
SOPS</strong> (Secrets OPerationS): bir YAML/JSON/env dosyasının sadece
değerlerini</strong> şifreliyor, key'leri (alan adlarını) düz bırakıyor. Yani dosya
hala okunabilir yapıda duruyor, ama değerler şifreli. Diff aldığımızda "hangi
alan değişmiş" görünüyor, değerin kendisi görünmüyor.</li>
</ul>
age asimetrik anahtarla çalışıyor: bir public/private key çifti üretiyoruz.
Veriyi public key</strong> ile şifreliyoruz ve o veri yalnızca eşleşen private key</strong>
ile açılıyor, başka hiçbir anahtarla değil. Asimetri de burada: public key'i
herkese verebiliriz, herkes onunla bize şifreli veri hazırlayabilir, ama açabilen
tek taraf private key'in sahibi. Yani şifreleyebilmek herkese açık bir yetenek,
çözebilmek tek elde. (GPG de temelde aynı asimetrik mantıkla çalışıyor, public
ile şifrele, private ile aç.)</p>
age'in GPG'den farkı ağırlıkta. GPG (GNU Privacy Guard) güçlü ama hantal:
web-of-trust denen bir güven modeli, keyring yönetimi, keyserver'lar, anahtar
son kullanma tarihleri, subkey'ler, arka planda çalışan agent süreçleri,
düzinelerce alt komut. Daha bir dosyayı şifreleyene kadar epey kavram öğrenmek
gerekiyor. age tek işe odaklı: config dosyası yok, anahtarlar kısa, komutlar tek
satır. Gündelik secret şifrelemede GPG'nin bütün o düzeneğine çoğu zaman ihtiyaç
olmuyor; age aynı işi çok daha sade yapıyor.</p>
Bunları birleştirince şunu elde ediyoruz: secret dosyası git'e commit'lenebilir.
Çünkü içindeki değerler age ile şifreli. Private key'i olmayan biri clone'lasa
bile işe yaramaz bir şifreli metin görür. Kim ne zaman değiştirmiş git
history'de duruyor. Yeni makinede tek git clone</code> (bir de age anahtarı) ile her
şey geliyor.</p>
Şunu da baştan söyleyeyim: bu yaklaşım küçük ve orta ölçekli projeler için
biçilmiş kaftan. Ama bir sınırı var. Public key'ler .sops.yaml</code>'da açıkta
olduğu için, repoya yazma erişimi olan herkes secret'ların değerini okuyamasa
bile üzerine yeni değer yazabiliyor (aşağıda "Şifreleyebilmek okuyabilmek değil"
bölümünde açıyorum). Küçük ve güvenilir bir ekipte bu kabul edilebilir bir risk.
Ekip ve etki alanı büyüdükçe git tarafında ekstra korumalar (branch protection,
zorunlu review, secret path'ine özel kurallar) ya da bir noktadan sonra merkezi
bir secret manager gerekiyor.</p>
Kurulum</h2>
macOS'ta ikisi de brew'da:</p>
brew</span> install</span> sops</span> age</span></span></code></pre>1. age anahtarı üret</h2>
age-keygen</span> -</span>o</span> key.txt</span></span></code></pre>
Çıktısı şöyle bir dosya:</p>
# created: 2026-08-12T12:02:42+03:00</span></span>
# public key: age1cpyuq5ss7w85phtrkhsxntek7k4ypx3gr8qa8c4vd5y0k772wqssrd4w4q</span></span>
AGE-SECRET-KEY-1DC8QTSCYAXRADPLAQA853TMCYDYZXSJ9JW8MFWRYLZFM6J4E67CS3K6ZW5</span></span></code></pre>
Üstteki age1...</code> satırı public key</strong> (recipient). Alttaki AGE-SECRET-KEY-...</code>
private key</strong>. Public key ile şifreliyoruz, private key ile açıyoruz. Private
key gizli kalıyor, public key'i rahatça paylaşabiliyoruz. Gerçekte private key
her makinede ~/.config/sops/age/keys.txt</code> altında durur ve asla commit'lenmez.</p>
2. Dosya düzeni: secrets/ ve .env.enc</h2>
Kendi kurulumumda secret'ları bir secrets/</code> dizininde, ortam başına ayrı
tutuyorum. Her ortam için üç dosya var:</p>
secrets/</span></span>
  app.local.env.enc         # şifreli, commit'li</span></span>
  app.local.env.example     # sadece key'ler, commit'li (hangi secret'lar var belli olsun)</span></span>
  app.local.env             # düz metin working file, GITIGNORE (lokal, çözülmüş kopya)</span></span></code></pre>
Mantık şu: .enc</code> şifreli ve commit'lenen dosya; .example</code> sadece anahtar
isimlerini taşıyan, yeni gelenin "hangi değerleri doldurmam lazım" diye bakacağı
template; düz .env</code> ise düzenlerken oluşan çözülmüş kopya, .gitignore</code>'da durur
ve hiçbir zaman commit'lenmez.</p>
.enc</code> uzantısının bir faydası da CI tarafında: pipeline secrets/*.env.enc</code>
gibi bir kalıpla tüm şifreli dosyaları tek seferde bulup topluca çözebiliyor.
Buradaki *</code> bir joker karakter; "bu desene uyan bütün dosya isimlerini getir"
demek. Dosya isimlerini böyle desenle eşleştirmeye glob deniyor (secrets/</code>
dizininde .env.enc</code> ile biten ne varsa hepsi). Uzantı ayrıca "bu dosya şifreli,
deploy'da çözülecek" sinyali oluyor.</p>
Bir nokta: .enc</code> uzantısı SOPS'a formatı söylemiyor. Dosyalar dotenv
(KEY=value</code>) formatında, ama SOPS bunu uzantıdan çıkaramadığı için her komutta
formatı elle vermek gerekiyor: --input-type dotenv --output-type dotenv</code>.
Aşağıdaki küçük yönetici bunu hep otomatik ekliyor.</p>
3. Kime şifreleniyor: .sops.yaml</h2>
SOPS'a hangi dosyayı kimin için şifreleyeceğini .sops.yaml</code> söylüyor. Ortam
başına farklı recipient'lar tanımlıyoruz. Önce anahtarları anchor olarak bir kere
yazıp aşağıda referans veriyoruz:</p>
#</span> .sops.yaml</span></span>
k</span>eys</span>:</span></span>
  -</span> &</span>local</span>          a</span>ge1cpyuq5ss...</span>   #</span> benim makinem</span></span>
  -</span> &</span>server_staging</span> a</span>ge12clzmdhl...</span>   #</span> staging sunucusu</span></span>
  -</span> &</span>server_prod</span>    a</span>ge1g5uwzup8...</span>   #</span> prod sunucusu</span></span>
</span>
c</span>reation_rules</span>:</span></span>
  #</span> local: sadece benim makinem açabilir</span></span>
  -</span> p</span>ath_regex</span>:</span> s</span>ecrets[/\\]app\.local\.env(\.enc)?$</span></span>
    k</span>ey_groups</span>:</span></span>
      -</span> a</span>ge</span>:</span></span>
          -</span> *</span>local</span></span>
</span>
  #</span> staging: staging sunucusu + ben</span></span>
  -</span> p</span>ath_regex</span>:</span> s</span>ecrets[/\\]app\.staging\.env(\.enc)?$</span></span>
    k</span>ey_groups</span>:</span></span>
      -</span> a</span>ge</span>:</span></span>
          -</span> *</span>server_staging</span></span>
          -</span> *</span>local</span></span>
</span>
  #</span> prod: prod sunucusu + ben</span></span>
  -</span> p</span>ath_regex</span>:</span> s</span>ecrets[/\\]app\.prod\.env(\.enc)?$</span></span>
    k</span>ey_groups</span>:</span></span>
      -</span> a</span>ge</span>:</span></span>
          -</span> *</span>server_prod</span></span>
          -</span> *</span>local</span></span></code></pre>
Buradaki recipient modeli önemli: her ortam o ortamın sunucu public key'i +
benim local public key'im</strong> ile şifreleniyor. Sonuç:</p>

Sunucu deploy anında kendi private key'i ile açıyor.</li>
Ben local'de kendi private key'imle açıp düzenliyorum.</li>
Prod dosyasını sadece prod sunucusu (bir de ben) açabiliyor; staging sunucusu
ya da başka bir geliştirici prod secret'ını çözemiyor, çünkü onların key'i o
kuralda yok.</li>
</ul>
.sops.yaml</code>'a yazdığımız age1...</code> satırlarının hepsi public key</strong>. Hiçbir
private key buraya girmiyor.</p>
sops+age kurulumunu ilk zamanlar biraz ezbere yapıyordum; bu yapının nasıl
işlediğini tam bilmiyordum. O zaman dokümanın tamamını okumamıştım, açıkçası
deneyimim de yoktu. Sonradan fark ettim ki buradaki key_groups</code> aslında dikkat
isteyen bir ifade: prod kuralına "local için de encrypt et" dediğimiz an, prod
secret'ı local'de de çözülebilir hale geliyor. SOPS bir değeri şifrelerken önce
rastgele bir data key üretiyor, asıl veriyi onunla şifreliyor, sonra o data key'i
gruptaki her recipient'ın public key'ine ayrı ayrı sarıyor. Yani prod dosyasındaki
data key hem prod sunucusunun private key'iyle hem benim local private key'imle
açılabiliyor; ikisinden biri yetiyor. Prod secret'larını local'de sops -d</code> ile
çözebildiğimi görünce açıkçası çok şaşırmıştım; ilk anda "acaba bir zafiyet mi
var" diye düşündüm. Değil: bu tam da her ortamın key group'una &local</code>'i
eklememin sonucu, tasarımın kendisi. Aynısı staging/qa için de geçerli: kuralda
&local</code> recipient olduğu sürece o ortamı local'de açabiliyorum.</p>
Ama getirdiği trade-off'u görmek gerekiyor: local private key'i eline geçiren
biri, o key'in recipient olduğu her ortamın (prod dahil) secret'larını çözebilir.
Yani keys.txt</code> dosyasını korumak ve kimin hangi ortama recipient olduğunu
bilinçli seçmek önemli. Küçük ve güvenilir bir ekipte bu kabul edilebilir bir
kolaylık. Erişimi daraltmak istersek local'i prod grubundan çıkarıp prod'u
sadece sunucu key'iyle şifreleriz; o zaman prod secret'ını kimse local'de
açamaz.</p>
(path_regex</code>'teki secrets[/\\]</code> hem /</code> hem \</code> ayıracını kapsıyor: bir Windows
portability detayı, aşağıdaki encoding bölümünde değiniyorum.)</p>
Bir de terim notu: buradaki key_groups</code>, bir grup içinde recipient'ları saran
bir konteyner sadece. Ortam ayrımı için tek grup ve o gruba yazdığımız recipient
listesi yeterli.</p>
Tam dosya:
https://github.com/erdyasan/sops-age-example/blob/811a70873d040b2be83f68f5cfaaf972cef7deeb/.sops.yaml</p>
4. Secret'i yaz ve şifrele</h2>
Önce düz working file'ı hazırlıyoruz (dotenv):</p>
# secrets/app.local.env  (gitignore'lı, düz metin)</span></span>
HELLO=world</span></span>
FAKE_API_KEY=demo_local_sk_0000</span></span>
DB_PASSWORD=local-demo-password</span></span></code></pre>
Sonra şifreliyoruz (dotenv formatını elle vererek):</p>
sops</span> -</span>e</span> -</span>-input-type</span> dotenv</span> -</span>-output-type</span> dotenv</span> secrets/app.local.env</span> ></span> secrets/app.local.env.enc</span></span></code></pre>
.enc</code> dosyası artık şöyle görünüyor:</p>
HELLO=ENC[AES256_GCM,data:wPU91TF7...,iv:bbS2qHGd...,tag:ALssHW9H...,type:str]</span></span>
FAKE_API_KEY=ENC[AES256_GCM,data:...,type:str]</span></span>
DB_PASSWORD=ENC[AES256_GCM,data:...,type:str]</span></span>
sops_age__list_0__map_recipient=age1cpyuq5ss...</span></span>
sops_mac=ENC[AES256_GCM,...]</span></span>
sops_version=3.13.2</span></span></code></pre>
Alan adları (HELLO</code>, FAKE_API_KEY</code>, DB_PASSWORD</code>) düz, değerleri şifreli. İşte
bu yüzden diff'ler anlamlı kalıyor. Alttaki sops_...</code> satırları SOPS'un
metadata'sı: hangi recipient için şifrelendiği ve bütünlük kontrolü (mac</code>). YAML
kullansaydık bu bir sops:</code> bloğu olurdu; dotenv düz key=value tuttuğu için
metadata da sops_...</code> şeklinde düz anahtarlara yayılıyor.</p>
Bu .enc</code> dosyasını rahatça commit'leyebiliyoruz. Düz app.local.env</code>'i ise git
görmüyor.</p>
5. Runtime'da açmak</h2>
Şifreli dosya güzel de, uygulama bunu nasıl okuyacak? En temiz yol düz metni hiç
diske yazmamak: dosyayı bellekte çözüp değerleri ortam değişkeni olarak process'e
enjekte etmek.</p>
Bunun için repoya küçük bir yönetici koydum (secrets.mjs</code>), gerçek projemdeki
daha kapsamlı halinin sadeleştirilmişi. Kendi kripto'yu yapmıyor, sadece sops</code>
CLI'ını çağırıyor. run</code> komutu ortamı çözüp verilen komutu o değişkenlerle
çalıştırıyor:</p>
node</span> secrets.mjs</span> run</span> local</span> -</span>-</span> node</span> index.js</span></span></code></pre>
Uygulama tarafı sadece process.env</code>'i okuyor, SOPS'tan haberi bile yok:</p>
//</span> index.js</span></span>
const</span> KEYS</span> =</span> [</span>"</span>HELLO</span>"</span>,</span> "</span>FAKE_API_KEY</span>"</span>,</span> "</span>DB_PASSWORD</span>"</span>]</span>;</span></span>
</span>
console</span>.</span>log</span>(</span>"</span>Secrets decrypted by SOPS, read from process.env:</span>\n</span>"</span>)</span>;</span></span>
for</span> (</span>const</span> key</span> of</span> KEYS</span>)</span> {</span></span>
  console</span>.</span>log</span>(</span>`</span>  ${</span>key</span>}</span> = </span>${</span>process</span>.</span>env</span>[</span>key</span>]</span> ??</span> "</span>(missing)</span>"</span>}</span>`</span>)</span>;</span></span>
}</span></span></code></pre>
Çıktı:</p>
$ npm start</span></span>
</span>
Secrets decrypted by SOPS, read from process.env:</span></span>
</span>
  HELLO = world (local)</span></span>
  FAKE_API_KEY = demo_local_sk_0000_not_a_real_key</span></span>
  DB_PASSWORD = local-demo-password</span></span></code></pre>
Neden sops exec-env</code> değil de kendi küçük script'im? Çünkü exec-env</code>,
--input-type</code> bayrağını kabul etmiyor; formatı uzantıdan çıkaramadığı için
uzantısız/.enc</code> dotenv dosyalarında işe yaramıyor. Node tarafında sops -d --input-type dotenv ...</code> ile çözüp çıktıyı parse etmek hem bu sorunu çözüyor hem
de boşluk içeren değerleri (world (local)</code> gibi) shell'in bozmasına izin
vermiyor. Çözülmüş içerik hiçbir zaman diske yazılmıyor, sadece process yaşadığı
sürece bellekte duruyor.</p>
Yöneticinin tamamı:
https://github.com/erdyasan/sops-age-example/blob/811a70873d040b2be83f68f5cfaaf972cef7deeb/secrets.mjs</p>
Ekip: anahtar paylaşmak değil, recipient eklemek</h2>
Başta tek bir anahtar çifti ürettik, çünkü tek kişiydik. Peki ekip olunca ne
oluyor, herkese aynı private key'i mi dağıtıyoruz? Hayır. İşin püf noktası tam
burada.</p>
Ekipteki her kişi kendi makinesinde age-keygen</code> çalıştırıp kendine ait bir çift
üretiyor: kendi private key'i (gizli, makinesinden çıkmaz) ve kendi public key'i
(paylaşılabilir). Yani ortada tek bir public key yok; her üyenin farklı bir çifti
var. .sops.yaml</code>'daki age1...</code> satırlarının hepsi public key.</p>
SOPS bir dosyayı şifrelerken şöyle çalışıyor: rastgele bir veri anahtarı (data
key) üretir, asıl değerleri onunla şifreler, sonra bu veri anahtarını o kuraldaki
her recipient'ın public key'i ile ayrı ayrı sarmalar (wrap). Böylece listedeki
herhangi bir kişi (ya da sunucu) kendi private key'i ile veri anahtarını açıp
dosyayı çözebiliyor. Herkesin ayrı private key'i olduğu için kimse başkasının
anahtarını bilmek zorunda değil.</p>
Neden böyle? Çünkü tek bir private key'i herkese dağıtsaydık: biri sızdırınca
hepsi birden yanardı, kimin açtığı belli olmazdı ve anahtarı değiştirmek için
herkese yeniden dağıtmamız gerekirdi. Ayrı ayrı olunca sadece public key'ler
paylaşılıyor, private key'ler makineden hiç çıkmıyor.</p>
Yeni biri katılınca, onun public key'ini ilgili kurala ekliyoruz, sonra dosyayı
onun için de sarmalamak üzere:</p>
sops</span> updatekeys</span> secrets/app.local.env.enc</span></span></code></pre>
Biri ayrılınca: public key'ini .sops.yaml</code>'dan çıkarıyoruz, sops updatekeys</code>
çalıştırıyoruz, bir de gerçek secret değerlerini rotate ediyoruz. (Ayrılan kişi
eski commit'teki şifreli dosyayı hala açabilir, çünkü history'de o versiyon
duruyor. O yüzden değeri değiştirmek şart.)</p>
CI (GitHub Actions)</h2>
CI ortamında o ortamın private key'ini repo secret'ı olarak veriyoruz:</p>
-</span> r</span>un</span>:</span> n</span>ode secrets.mjs run prod -- node index.js</span></span>
  e</span>nv</span>:</span></span>
    S</span>OPS_AGE_KEY</span>:</span> $</span>{{ secrets.PROD_AGE_KEY }}</span></span></code></pre>
SOPS_AGE_KEY</code> anahtarın içeriğini doğrudan alır; SOPS_AGE_KEY_FILE</code> ise bir
dosya yolu ister. İstediğim şey de tam buydu: CI'a hiç dokunmadan, şifreli
dosyayı commit'leyerek secret güncelliyorum ve prod anahtarı sadece prod CI'ının
secret'ında durduğu için ortam izolasyonu bozulmuyor.</p>
Şifreleyebilmek okuyabilmek değil: repo erişimi</h2>
Bir noktada şunu fark ettim: public key'ler .sops.yaml</code>'da açıkta
duruyor. Peki repoya yazma erişimi olan biri secret'ları değiştirebilir mi? Evet,
değiştirebilir. Şifrelemek için sadece public key yetiyor, private key
gerekmiyor. Yani o kişi mevcut değerleri okuyamaz</strong> (okumak private key ister),
ama üzerlerine yeni değer yazıp yeniden şifreleyip commit'leyebilir. Deploy'da
sunucu commit'lenmiş değeri çözüp kullandığı için, yazma erişimi olan biri
DB_PASSWORD</code>'ü farklı bir değere çekebilir ya da bir API adresini yanlış bir
yere yönlendirebilir.</p>
Yani SOPS bize gizlilik</strong> (confidentiality) veriyor, bütünlük</strong> (integrity)
değil. Değerleri okumaya karşı korur, değiştirilmeye karşı korumaz. Küçük projede
bu genelde yeterli; ölçek büyüdükçe bu boşluğu git tarafında kapatmak gerekiyor.
sops'u bir ekipte kullanmaya karar verilirse önerim şu birkaç önlem:</p>


Branch protection + zorunlu review.</strong> main</code>'e doğrudan push'u kapatmak, her
değişikliği PR + onay ile almak. Böylece kimse tek başına secret'ın üzerine
yazıp deploy'a gönderemez.</p>
</li>

Secret path'ine özel reviewer (CODEOWNERS).</strong> secrets/</code> ve .sops.yaml</code>'a
dokunan her PR'a belirli kişilerin onayını zorunlu kılmak.</p>
</li>

PR'da otomatik uyarı.</strong> secret dosyalarına dokunan bir PR açıldığında oraya
otomatik bir uyarı yorumu düşürmek. Böylece o değişiklik reviewer'ın gözünden
kolayca kaçmıyor. İstersek bunu required status check'e bağlayıp onaysız
merge'ü de engelleyebilir, daha ileri gidip commit imzalama ekleyebiliriz.</p>
</li>
</ul>
Not: SOPS'taki mac</code> alanı dosyanın elle (sops kullanmadan) kurcalanmasını
yakalar, ama sops ile düzgünce yeniden şifreleyen biri geçerli bir mac</code> üretir.
Yani mac</code> kör hex editini engeller, yetkili birinin yeniden şifrelemesini değil.</p>
Dikkat edilecek nokta: metadata sızar</h2>
SOPS sadece değerleri</strong> şifreliyor, alan adları düz kalıyor</strong>. Diff'ler
okunabilir olsun diye böyle, ama bunun bedeli var: dosyaya bakan biri hangi
secret'lardan bahsedildiğini görür. DB_PASSWORD</code>, STRIPE_SECRET_KEY</code>,
ADMIN_TOKEN</code>... değerleri gizli ama isimleri altyapının şeklini ele veriyor.
Alan adının kendisi hassassa, ya bütün dosyayı şifrelemek ya da ismini
nötrleştirmek gerekiyor.</p>
Satır sonu (CRLF/LF) ve encoding tuzağı</h2>
Bununla deploy tarafında baya uğraştım, en sinir bozucu kısım buydu. .enc</code>
dosyasını bir makinede (mac, LF satır sonu) oluşturdum, sonra aynı repoyu
Windows'ta açtım. Değerler doğruydu ama decrypt bir türlü olmuyordu. Sebep: SOPS
her dosya için içeriğin üzerinden bir mac</code> (bütünlük kontrolü) hesaplıyor.
Byte'lar bir tık değişince mac tutmuyor ve dosya bozuk sayılıyor. Windows'ta bu
byte'ları değiştiren birkaç ayrı şey var.</p>
1. Git autocrlf.</strong> Windows'ta git checkout sırasında LF'leri CRLF'e
çevirebiliyor. .enc</code>'in byte'ları değişiyor, mac patlıyor. Çözüm .gitattributes</code>
ile bu dosyalarda dönüşümü kapatmak:</p>
# .gitattributes</span></span>
secrets/*.enc -text</span></span></code></pre>
-text</code>, git'e "bu dosyaları metin sayma, satır sonlarına dokunma" diyor.</p>
2. PowerShell ></code> yönlendirmesi UTF-16 yazıyor.</strong> Bunu bulmak zaman aldı.
Windows'ta sops -e ... > dosya.enc</code> yapınca, PowerShell'in ></code> operatörü çıktıyı
UTF-8 değil UTF-16 LE</strong> olarak yazıyor, üstüne bir de BOM ekliyor. Dosya daha
baştan bozuk doğuyor. Editörlerin araya kattığı BOM da aynı sonucu veriyor.</p>
Bu yüzden Windows için küçük bir PowerShell script'i yazdım (encrypt.ps1</code>).
Kabaca: önce plaintext'i LF-only + UTF-8 no BOM'a normalize ediyor, sonra sops
çıktısını ></code> ile değil bir değişkene alıp .NET File API ile (yine LF + UTF-8 no
BOM, sonda tek newline) yazıyor, en sonunda dosyanın ilk byte'larına bakıp
UTF-16/UTF-8 BOM ya da CRLF varsa hata fırlatıyor. Yani bozuk bir .enc</code> üretmeyi
baştan imkansız kılıyor. Tamamı repoda:
https://github.com/erdyasan/sops-age-example/blob/811a70873d040b2be83f68f5cfaaf972cef7deeb/encrypt.ps1</p>
3. Path ayıracı.</strong> Küçük ama can sıkan bir başka Windows farkı .sops.yaml</code>'daki
path_regex</code>. sops, dosya yolunu OS'un verdiği haliyle regex'e geçiriyor;
Windows'ta ayıraç \</code> olduğu için sadece /</code> ile yazılmış bir pattern eşleşmiyor
ve dosya "hangi kurala ait" bulunamıyor. Yukarıda .sops.yaml</code> örneğinde
path_regex</code>'i secrets[/\\]...</code> diye yazmamın sebebi bu: köşeli parantez iki
ayıracı da kapsıyor.</p>
Özet: .enc</code> dosyalarının byte'ları aynen korunmalı. Satır sonu, encoding, BOM,
araya giren her şey mac'i bozuyor. .enc</code>'i elle editörde açıp kaydetmemek
gerekiyor; hep araçlar (sops, secrets.mjs, encrypt.ps1) üzerinden düzenliyoruz.
Dosyaların encoding'i önemli.</p>
SOPS ne zaman, alternatifler ne zaman</h2>

git-crypt</strong>: bütün dosyayı şifreler, şeffaf çalışır (checkout'ta açılır). Ama
değer değil dosya bazlı olduğu için diff'ler okunmaz. Alan adı sızmasını
istemiyorsak avantaj.</li>
Vault / cloud secret manager (Azure Key Vault, AWS Secrets Manager)</strong>:
merkezi, audit log'lu, dinamik secret üreten ağır çözümler. Büyük ekip ve sıkı
uyumluluk gereksinimi varsa doğru yer. Ama ayağa kaldırmak ve işletmek
maliyetli.</li>
SOPS + age</strong>: küçük/orta projeler için tatlı nokta. Ekstra bir servis yok,
secret kodla aynı yerde versiyonlu, kurulum bir avuç komut. GitOps akışlarına
da iyi oturuyor.</li>
</ul>
"Zaten private repomuz var, üstüne bir de şifrelemek gereksiz mi?" diye
sorulabilir. Bence değil: defense in depth. Repo yanlışlıkla public olursa, bir
fork sızarsa ya da birinin GitHub token'ı çalınırsa düz .env</code> anında ele geçer;
şifreli dosya hala private key olmadan işe yaramaz.</p>
Sonuç</h2>
Secret'ları repoda şifreli tutmak, "ayrı bir yerde secret saklama" derdini büyük
ölçüde ortadan kaldırıyor. SOPS + age ile kurulum birkaç komut, günlük kullanım
neredeyse görünmez. Küçük projelerde Vault'a gerek kalmadan makul bir güvenlik ve
rahat bir iş akışı sağlıyor.</p>
Tam çalışan demo, tüm dosyalarıyla:
https://github.com/erdyasan/sops-age-example</p>


Cloudflare ve Gmail ile Kendi Domain'inden Ücretsiz E-posta
2026-08-10T00:00:00+00:00
E-posta gönderimlerini custom domain ile yapmak daha profesyonel duruyor. Hatta
çoğu hosting firması bunu bir artı özellik olarak sunuyor. Ama kendi e-posta
sunucunu kurmak ve bununla uğraşmak gerçekten külfet. İşin içine SPF kaydı,
domain doğrulama, hatta reverse DNS giriyor. MX kaydı da var bu işlerin. Yani
mailin düzgün teslim edilsin istiyorsan uğraşacağın bir sürü ayar var.</p>
Çoğu firma bunları senin yerine otomatik hallediyor tabii. Ama custom bir e-posta
servisi istersen bu challenge'lar karşına çıkıyor.</p>
Her neyse. Son dönemde web sitemi statik tutmaya karar verdim, admin panelim yok.
Özetle arkada sürekli çalışan bir hosting ya da VPS de yok, dolayısıyla sunucu
masrafım olmuyor. E-posta gönderimini kurumsal kimlik/imaj açısından nasıl
çözerim diye araştırınca Gmail'de başka bir kişi olarak mail gönderebildiğini
gördüm. Zaten Cloudflare kullanırken mail forwarding yapıyordum: mesela
iam@erdincyasan.com</code>'a mail atarsanız benim şahsi hesabıma, erdincyasan@gmail.com</code>'a
düşüyor.</p>
Şimdi gelin hep beraber bu ayarları nasıl yaptığımızı anlatmaya devam edelim.</p>
Ön koşullar</h2>

Domain'in DNS'i Cloudflare'de yönetiliyor olmalı (nameserver'lar Cloudflare'e
bakıyor olacak).</li>
Bir Gmail hesabı.</li>
Gmail hesabında 2 adımlı doğrulama (2FA) açık. App password üretmek için bu
şart, sonra değineceğim.</li>
</ul>
Adım 1: Cloudflare Email Routing ile mail almak</h2>
Cloudflare dashboard'da domain'ini seç, sol menüden Email > Email Routing</strong>'e
gir. İlk kez açıyorsan seni bir kurulum akışına alıyor.</p>
İki şey yapıyorsun:</p>


Destination address ekle.</strong> Maillerin nereye düşeceğini söylüyorsun, yani
kendi Gmail adresin (erdincyasan@gmail.com</code>). Cloudflare buraya bir doğrulama
maili gönderiyor, linke tıklayıp adresi onaylıyorsun. Onaylamadan yönlendirme
çalışmaz.</p>
</li>

Routing kuralı ekle.</strong> Örneğin iam@erdincyasan.com</code>'a gelen her şey
erdincyasan@gmail.com</code>'a gitsin. İstersen tek tek adres kuralı yazarsın,
istersen catch-all</strong> açarsın (domain'e gelen ne varsa hepsi tek kutuya).
Catch-all pratik ama spam'i de topluyor, ona göre.</p>
</li>
</ol>
Email Routing'i enable edince Cloudflare senin adına otomatik olarak gerekli DNS
kayıtlarını ekliyor. Elle uğraşmana gerek yok, ama ne eklendiğini bilmek iyi:</p>

Üç tane MX</strong> kaydı (route1.mx.cloudflare.net</code>, route2...</code>, route3...</code>
şeklinde, farklı öncelik değerleriyle). Bunlar "bu domain'in maili buraya
gelsin" diyen kayıtlar.</li>
Bir SPF</strong> kaydı (TXT): v=spf1 include:_spf.mx.cloudflare.net ~all</code>.</li>
Bir de DKIM</strong> kaydı (TXT, cf2024-1._domainkey...</code> gibi). Bu Cloudflare'in
kendi mail yolu için imza kaydı; Gmail'den giden mailde işe yaramıyor, ona
aşağıda "Sınırlar" bölümünde değineceğim.</li>
</ul>
Bu kadar. Artık iam@erdincyasan.com</code>'a gelen mailler Gmail'ine düşüyor. Test
et: başka bir hesaptan bu adrese bir mail at, Gmail'e geliyor mu bak.</p>
Adım 2: Gmail app password üretmek</h2>
Şimdi giden tarafa geliyoruz. Gmail'in normal şifresiyle SMTP'ye bağlanamıyorsun,
Google bunu reddediyor. Onun yerine app password</strong> denen 16 karakterlik özel
bir şifre üretiyorsun.</p>
Bunun ön koşulu 2FA'nın açık olması. 2FA kapalıysa app password ekranı hiç
görünmüyor.</p>

Google hesabına gir: Google Account > Security</strong>.</li>
2 adımlı doğrulama açık değilse önce onu aç.</li>
Ardından App passwords</strong> bölümüne git (arama kutusuna "app passwords"
yazarsan direkt bulursun).</li>
Yeni bir app password oluştur, bir isim ver (mesela "Gmail SMTP").</li>
Google sana boşluklu görünen 16 karakterlik bir kod veriyor
(abcd efgh ijkl mnop</code> gibi). Bu kodu bir yere kaydet, ekrandan çıkınca bir
daha göstermiyor.</li>
</ul>
Burada bir nokta var: Google şifreyi araya boşluk koyarak gösteriyor ama SMTP
ayarına girerken bu boşlukları silerek, bitişik girmen gerekiyor. Adım 3'te SMTP
server bilgilerini doldururken buna dikkat et, yoksa şifre kabul edilmiyor.</p>
Adım 3: Gmail'e custom adresi tanıtmak (Send mail as)</h2>
Son adım, Gmail'e "ben bu adresle de gönderebilirim" demek.</p>

Gmail > Settings (dişli) > See all settings > Accounts and Import</strong>.</li>
Send mail as</strong> bölümünde Add another email address</strong>'e tıkla.</li>
Ad ve göndermek istediğin adresi gir: iam@erdincyasan.com</code>.</li>
Treat as an alias</strong> kutusu çıkıyor. Bunu işaretli bırakabilirsin; işaretini
kaldırırsan alıcı tarafında "on behalf of" gibi bir ibare çıkabiliyor. İlk
kurulumda işaretli bırakmak en temiz sonucu veriyor.</li>
Sonraki ekranda SMTP bilgilerini istiyor:</li>
</ul>
SMTP Server : smtp.gmail.com</span></span>
Port        : 465  (SSL)   ya da   587 (TLS)</span></span>
Username    : erdincyasan@gmail.com   (tam Gmail adresi, sadece "erdincyasan" değil)</span></span>
Password    : ürettiğin 16 haneli app password (boşluksuz, bitişik gir)</span></span></code></pre>

Kaydedince Google iam@erdincyasan.com</code>'a bir doğrulama kodu yolluyor. Bu
mail Adım 1 sayesinde Gmail'ine düşüyor. Koddaki linke tıkla ya da kodu gir.</li>
</ul>
Bittiğinde Gmail'de yeni mail yazarken "From" alanından iam@erdincyasan.com</code>'u
seçebiliyorsun. Gelen de Gmail'de, giden de Gmail'de. Tek kuruş ödemedin.</p>
Takıldığın yer: 535-5.7.8 Username and Password not accepted</code></h2>
Adım 3'te SMTP kaydederken en çok bu hatayı alıyorsun. Sebepleri sırasıyla:</p>

Normal Gmail şifreni girmişsin.</strong> App password kullanman lazım.</li>
2FA kapalı.</strong> App password üretemeyeceğin için zaten yanlış bir şey giriyorsun.</li>
Username eksik.</strong> erdincyasan</code> değil, tam adres: erdincyasan@gmail.com</code>.</li>
App password'un boşluklarını silmemişsin.</strong> Google kodu abcd efgh ijkl mnop</code>
gibi boşluklu gösteriyor; SMTP'ye bitişik (abcdefghijklmnop</code>) girmen gerekiyor.</li>
Kopyalarken görünmez karakter kaçmış.</strong> App password'u elle, dikkatli gir.</li>
</ul>
Sınırlar (dürüst olmak gerekirse)</h2>
Bu kurulum bedava ve işini görüyor ama sihir değil:</p>

Gerçek bir mailbox değil. Cloudflare tarafında mail saklanmıyor, sadece
forward. Gmail'in silersen o mail gitti.</li>
Giden mail teknik olarak Gmail sunucusundan çıkıyor. Bu yüzden SPF/DKIM
hizalaması (alignment) domain'inle tam</strong> örtüşmüyor; header'da Gmail izleri
kalıyor. Kişisel/küçük kullanım için sorun değil, ama kurumsal bir mail
altyapısı arayan biri için yeterli değil.</li>
Ciddi gönderim hacmin varsa ya da teslimat garantisi önemliyse, ayrı bir mail
sağlayıcısı (Zoho, Google Workspace gibi) ya da transactional bir SMTP servisi
daha doğru olur.</li>
</ul>
Ama "domain'imden profesyonel görünen bir adresim olsun, para ödemeyeyim" diyorsan
bu ikili tam da o iş için.</p>


Git'te Yerel Ignore Kuralları: .git/info/exclude ve core.excludesFile
2026-08-10T00:00:00+00:00
Giriş</h2>
Ekiple birlikte büyük bir proje üzerinde çalışıyorduk. Projede herkes Claude
kullanmıyordu. Ben ise pairing yaparken proje root'una sürekli bir şeyler
bırakıyordum. Bir konuyu tarayıp docs olarak .md çıktısı alıyordum, geçici json
dosyaları atıyordum, görseller koyuyordum. Bunların hiçbiri projeyle doğrudan
ilgili değildi.</p>
İki şey istemiyordum. Birincisi bu dosyaları .gitignore'a eklemek, çünkü
.gitignore commit'lenir ve ilişkisiz bir değişiklik olarak herkese gider.
İkincisi bunların file change'lerde gözükmesi, kendi yerel çalışmam yüzünden
diff'i kirletmek istemiyordum.</p>
Yani bana repoya hiç dokunmayan, sadece kendi makinemde geçerli bir ignore
çözümü lazımdı. Aradım ve buldum: .git/info/exclude.</p>
Üç yer, üç amaç</h2>
Git'te ignore kuralı yazabileceğin üç yer var, ve üçü de farklı bir işe yarıyor:</p>

.gitignore</code>: repo ile paylaşılan, commit'lenen, herkesi bağlayan kurallar.</li>
.git/info/exclude</code>: sadece senin makinen ve klonun için. Commit, push, clone
edilmez, takımdaki kimse görmez.</li>
core.excludesFile</code>: git config ile işaret ettiğin bir dosya. Global (tüm
repoların için, per-user) ya da tek repo için local olabilir.</li>
</ul>
Benim ihtiyacım ikincisiydi, ama üçünü de bilmek işine yarıyor.</p>
.git/info/exclude, kişiye özel ve repoya girmez</h2>
Bu tam benim aradığım şeydi. Kurallar sadece bende kalıyor, repoya hiç
dokunmuyor. Dosya zaten her repoda mevcut, ekstra bir şey yaratman gerekmiyor,
sonuna satır eklemen yeterli:</p>
echo</span> "</span>*.local</span>"</span> >></span> .git/info/exclude</span></span>
echo</span> "</span>scratch/</span>"</span> >></span> .git/info/exclude</span></span></code></pre>
Bunu yerelde test ettim. *.local</code> kuralını yazınca untracked note.local</code>
dosyası yoksayıldı:</p>
git</span> check-ignore</span> -</span>v</span> note.local</span></span>
#</span> .git/info/exclude:1:*.local	note.local</span></span></code></pre>
En güzel tarafı, bu dosya klonlanmıyor ve push edilmiyor. Yani proje root'una
attığım docs ve json dosyalarını burada tuttum, kimsenin diff'inde gözükmedi.</p>
Önemli tuzak: zaten tracked olan dosya</h2>
Burası çok yanlış biliniyor, o yüzden ayrı yazıyorum. Eğer bir dosya zaten
commit edilmişse (tracked), onu exclude'a eklemek hiçbir şey değiştirmiyor. Git
tracked dosyalara ignore kurallarını uygulamaz.</p>
Test ettim: tracked bir dosyayı exclude'a ekledim, git check-ignore -v</code> hiçbir
şey döndürmedi. Çünkü tracked dosya "ignored" sayılmıyor.</p>
Çözüm, önce dosyayı index'ten düşürmek. Çalışma dizinindeki dosya silinmiyor,
sadece git takibi bitiyor:</p>
git</span> rm</span> -</span>-cached</span> tracked.txt</span></span>
#</span> dosya diskte kalır, sadece git artık takip etmez</span></span>
#</span> bundan sonra .gitignore veya exclude kuralı devreye girer</span></span></code></pre>core.excludesFile, global kişisel ignore</h2>
Bir de her repoda tekrar tekrar yazmak istemediğin şeyler var. .DS_Store</code>,
.idea/</code>, *.swp</code> gibi. Bunları her projede ayrı ayrı yazmak yerine bir kere
merkezi tanımlayabilirsin:</p>
git</span> config</span> -</span>-global</span> core.excludesFile</span> ~/.gitignore_global</span></span>
echo</span> "</span>*.conf</span>"</span> >></span> ~/.gitignore_global</span></span></code></pre>
Yerelde denedim, *.conf</code> kuralı app.conf</code>'u yoksaydı:</p>
git</span> check-ignore</span> -</span>v</span> app.conf</span></span>
#</span> ~/.gitignore_global:1:*.conf	app.conf</span></span></code></pre>
Global şart değil, --global</code> olmadan git config core.excludesFile <yol></code>
diyerek tek repo için de kullanabilirsin.</p>
Öncelik sırası</h2>
Şimdi asıl kafa karıştıran yere geldik. Aynı dosya için birden fazla yerde kural
varsa kim kazanır? Yerelde test ettim, yüksekten düşüğe sıra şöyle:</p>

Komut satırı pattern'leri (git ls-files gibi)</li>
.gitignore</code> dosyaları (daha derin dizindeki kural üstünü ezer, aynı dosya
içinde son eşleşen kural kazanır)</li>
.git/info/exclude</code></li>
core.excludesFile</code></li>
</ol>
Bunu iki negation testiyle doğruladım. .gitignore</code> içine !note.local</code>
yazdığımda, exclude'daki *.local</code> kuralını ezdi ve dosya yoksayılmadı. Yani
.gitignore</code>, exclude'dan önceliklidir. Sonra exclude'a !build/</code> yazdığımda,
core.excludesFile'daki build/</code> kuralını ezdi. Yani exclude da
core.excludesFile'dan önceliklidir.</p>
Kısacası ortak kural (.gitignore</code>) her zaman kişisel kurallarını ezer. Bunu
akılda tutmak lazım.</p>
Hata ayıklama: bir dosya neden yoksayılıyor?</h2>
Bir dosyanın neden ignore edildiğini (ya da edilmediğini) merak ettiğinde tek
komut yetiyor:</p>
git</span> check-ignore</span> -</span>v</span> <</span>dosy</span>a</span>></span></span></code></pre>
-v</code> bayrağı hangi dosyanın, hangi satırın, hangi kuralın eşleştiğini gösteriyor:</p>
git</span> check-ignore</span> -</span>v</span> note.local</span></span>
#</span> .git/info/exclude:1:*.local	note.local</span></span></code></pre>
Çıktı gelmiyorsa iki ihtimal var: ya dosya ignore edilmiyor, ya da zaten tracked
(tracked dosyalar bu komutta raporlanmaz).</p>
Takım açısından: exclude mı, ortak kural mı?</h2>
Benim durumumda cevap netti. Attığım dosyalar tamamen kişiseldi, takımın
umurunda değildi, o yüzden .git/info/exclude</code> doğru seçimdi. Repoya dokunmadan
kendi kirimi kendi makinemde tuttum.</p>
Basit bir ayrım var kafamda:</p>

Sadece sana özgü şeyler (IDE ayarları, kişisel scratch, pairing artıkları):
.git/info/exclude</code> veya global core.excludesFile</code>. Repoyu kirletmez.</li>
Takımca ortak muaf tutulması gereken şeyler (node_modules/</code>, build çıktısı):
commit'lenen .gitignore</code>. Çünkü exclude paylaşılmıyor, herkesin aynı
davranışı görmesi gerekir.</li>
</ul>
Kapanış</h2>
Özetle, .gitignore tek yer değil. Kişisel işler için .git/info/exclude</code> ve
core.excludesFile</code> var, ve bunlar repoya hiç dokunmuyor. Bir daha proje
root'una geçici bir dosya bırakıp da "bunu nasıl gizlerim" diye düşündüğünde,
çözüm bu.</p>


PostgreSQL LIKE Performansı: CAST, Concat ve OR Karşılaştırması
2026-06-29T00:00:00+00:00
Geçenlerde gördüğüm bir sorgu üzerine düşünmeye başladım. LongColumn</code> (bigint</code>) ve Description</code> (text</code>) diye iki sütun vardı. Arama şöyle çalışıyordu:</p>
//</span> Eski kod: CAST + concat</span></span>
context</span>.</span>Documents</span></span>
    .</span>Where</span>(</span>d</span> =></span> EF</span>.</span>Functions</span>.</span>Like</span>(</span></span>
        d</span>.</span>LongColumn</span>.</span>ToString</span>(</span>)</span> +</span> "</span> "</span> +</span> d</span>.</span>Description</span>,</span> pattern</span>)</span>)</span></span></code></pre>
EF Core bunu LongColumn::text || ' ' || Description</code> olarak PostgreSQL'e gönderiyordu. bigint</code> bir sütunda LIKE aramak için önce ::text</code> cast edip Description ile birleştirmek gerekiyordu. Daha sonra LongColumn</code>'daki veriler TextColumn</code> adlı text</code> tipinde yeni bir sütuna taşındı. CAST ortadan kalktı.</p>
Peki şimdi sorguyu nasıl yazmalıyız? Altı farklı yol var:</p>
//</span> A: CAST + concat (eski yol)</span></span>
.</span>Where</span>(</span>d</span> =></span> EF</span>.</span>Functions</span>.</span>Like</span>(</span></span>
    d</span>.</span>LongColumn</span>.</span>ToString</span>(</span>)</span> +</span> "</span> "</span> +</span> d</span>.</span>Description</span>,</span> pattern</span>)</span>)</span></span>
</span>
//</span> B: CAST, tek sütun</span></span>
.</span>Where</span>(</span>d</span> =></span> EF</span>.</span>Functions</span>.</span>Like</span>(</span>d</span>.</span>LongColumn</span>.</span>ToString</span>(</span>)</span>,</span> pattern</span>)</span>)</span></span>
</span>
//</span> C: TextColumn concat</span></span>
.</span>Where</span>(</span>d</span> =></span> EF</span>.</span>Functions</span>.</span>Like</span>(</span></span>
    d</span>.</span>TextColumn</span> +</span> "</span> "</span> +</span> d</span>.</span>Description</span>,</span> pattern</span>)</span>)</span></span>
</span>
//</span> D: TextColumn tek sütun</span></span>
.</span>Where</span>(</span>d</span> =></span> EF</span>.</span>Functions</span>.</span>Like</span>(</span>d</span>.</span>TextColumn</span>,</span> pattern</span>)</span>)</span></span>
</span>
//</span> E: TextColumn OR Description (ayrı ayrı LIKE)</span></span>
.</span>Where</span>(</span>d</span> =></span> EF</span>.</span>Functions</span>.</span>Like</span>(</span>d</span>.</span>TextColumn</span>,</span> pattern</span>)</span></span>
         ||</span> EF</span>.</span>Functions</span>.</span>Like</span>(</span>d</span>.</span>Description</span>,</span> pattern</span>)</span>)</span></span>
</span>
//</span> F: LongColumn::text OR Description (CAST'li OR)</span></span>
.</span>Where</span>(</span>d</span> =></span> EF</span>.</span>Functions</span>.</span>Like</span>(</span>d</span>.</span>LongColumn</span>.</span>ToString</span>(</span>)</span>,</span> pattern</span>)</span></span>
         ||</span> EF</span>.</span>Functions</span>.</span>Like</span>(</span>d</span>.</span>Description</span>,</span> pattern</span>)</span>)</span></span></code></pre>
Hangisi daha hızlı? CAST maliyeti ne kadar? Concat index'i bozuyor mu? OR yaklaşımı index kullanabiliyor mu? Bu soruları cevaplamak için 2 milyon satırlık bir benchmark kurdum.</p>
Benchmark Kurulumu</h2>

PostgreSQL 16 (Docker), port 5433</li>
documents</code> tablosu: Id</code>, LongColumn (bigint)</code>, TextColumn (text)</code>, Description (text)</code> - 2 milyon satır</li>
TextColumn</code>: LongColumn</code>'ın string karşılığı + Türkçe metin. Ortalama 439 byte</li>
LongColumn</code>: rastgele 10 haneli bigint. String karşılığı ortalama 14 byte</li>
Description</code>: Türkçe metin, ortalama 423 byte</li>
Index'ler TextColumn</code> ve Description</code> üzerinde (bigint</code> sütuna text index'i oluşturulmaz)</li>
3 index stratejisi: Yok, B-tree, GIN trigram (pg_trgm</code>)</li>
3 pattern: %ankara%</code> (%42 satır), %de%</code> (</del>%99 satır), %xyzqwerty%</code> (hiç yok)</li>
Her senaryo 5 kez çalıştırıldı, en iyi/en kötü atıldı, 3'ünün ortalaması</li>
EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)</code> ile ölçüldü</li>
</ul>
EF Core'un Ürettiği SQL</h2>
A - CAST + concat</strong></p>
--</span> @__pattern_1='%ankara%'</span></span>
SELECT</span> d.</span>"</span>Id</span>"</span>, d.</span>"</span>Description</span>"</span>, d.</span>"</span>LongColumn</span>"</span>, d.</span>"</span>TextColumn</span>"</span></span>
FROM</span> documents </span>AS</span> d</span></span>
WHERE</span> d.</span>"</span>LongColumn</span>"</span>::</span>text</span> ||</span> '</span> '</span> ||</span> d.</span>"</span>Description</span>"</span> LIKE</span> @__pattern_1</span> ESCAPE </span>'</span>'</span></span></code></pre>
B - CAST, tek sütun</strong></p>
WHERE</span> d.</span>"</span>LongColumn</span>"</span>::</span>text</span> LIKE</span> @__pattern_1</span> ESCAPE </span>'</span>'</span></span></code></pre>
C - TextColumn concat</strong></p>
WHERE</span> d.</span>"</span>TextColumn</span>"</span> ||</span> '</span> '</span> ||</span> d.</span>"</span>Description</span>"</span> LIKE</span> @__pattern_1</span> ESCAPE </span>'</span>'</span></span></code></pre>
D - TextColumn tek sütun</strong></p>
WHERE</span> d.</span>"</span>TextColumn</span>"</span> LIKE</span> @__pattern_1</span> ESCAPE </span>'</span>'</span></span></code></pre>
E - TextColumn OR Description</strong></p>
WHERE</span> d.</span>"</span>TextColumn</span>"</span> LIKE</span> @__pattern_1</span> ESCAPE </span>'</span>'</span> OR</span> d.</span>"</span>Description</span>"</span> LIKE</span> @__pattern_1</span> ESCAPE </span>'</span>'</span></span></code></pre>
F - LongColumn::text OR Description</strong></p>
WHERE</span> d.</span>"</span>LongColumn</span>"</span>::</span>text</span> LIKE</span> @__pattern_1</span> ESCAPE </span>'</span>'</span> OR</span> d.</span>"</span>Description</span>"</span> LIKE</span> @__pattern_1</span> ESCAPE </span>'</span>'</span></span></code></pre>
d.LongColumn.ToString()</code> → LongColumn::text</code>. string + string</code> → ||</code>. ESCAPE ''</code> EF Core varsayılanı, performansa etkisiz.</p>
Sonuçlar - GIN Trigram İndex ile</h2>
En kritik senaryo GIN index varken. B-tree None ile aynı sonucu verdiği için atlıyorum - LIKE '%x%'</code> B-tree'nin çalışma prensibine ters.</p>
Yaklaşım</th> Pattern</th> Süre (ms)</th> Read Blocks</th> Satır</th></tr></thead>

A: CAST+concat</td> %ankara%</td> 702.35</td> 465,400</td> 1,036,239</td></tr>
A: CAST+concat</td> %de%</td> 645.73</td> 232,304</td> 1,991,384</td></tr>
A: CAST+concat</td> %xyzqwerty%</td> 468.41</td> 464,416</td> 0</td></tr>
B: CAST tek</td> %ankara%</td> 131.93</td> 459,568</td> 0</td></tr>
B: CAST tek</td> %de%</td> 328.45</td> 229,556</td> 0</td></tr>
B: CAST tek</td> %xyzqwerty%</td> 137.11</td> 457,680</td> 0</td></tr>
C: TextConcat</td> %ankara%</td> 996.65</td> 453,224</td> 1,729,401</td></tr>
C: TextConcat</td> %de%</td> 640.01</td> 226,244</td> 1,999,945</td></tr>
C: TextConcat</td> %xyzqwerty%</td> 780.89</td> 451,480</td> 0</td></tr>
D: TextSingle</td> %ankara%</td> 1,644.34</td> 224,260</td> 850,373</td></tr>
D: TextSingle</td> %de%</td> 552.69</td> 224,148</td> 1,987,804</td></tr>
D: TextSingle</strong></td> %xyzqwerty%</strong></td> 0.01</strong></td> 0</strong></td> 0</td></tr>
E: TextOR</td> %ankara%</td> 2,480.59</td> 223,484</td> 1,297,051</td></tr>
E: TextOR</td> %de%</td> 543.10</td> 223,204</td> 1,999,945</td></tr>
E: TextOR</strong></td> %xyzqwerty%</strong></td> 0.01</strong></td> 0</strong></td> 0</td></tr>
F: CAST OR</td> %ankara%</td> 1,776.36</td> 222,064</td> 777,179</td></tr>
F: CAST OR</td> %de%</td> 627.46</td> 221,848</td> 1,991,384</td></tr>
F: CAST OR</td> %xyzqwerty%</td> 459.11</td> 443,016</td> 0</td></tr>
</tbody></table>
Kritik Bulgu 1: GIN İndex - Kim Kullanıyor, Kim Kullanamıyor?</h2>
%xyzqwerty%</code> pattern'ine odaklanalım. Bu pattern hiçbir satırda yok - index'in gerçek etkisini en net burada görüyoruz:</p>
#</th> Yaklaşım</th> SQL Özeti</th> Süre</th> Tarama Tipi</th> İndex?</th></tr></thead>

A</td> CAST+concat</td> LongCol::text || Desc</code></td> 468ms</td> Seq Scan</td> ❌</td></tr>
B</td> CAST tek</td> LongCol::text</code></td> 137ms</td> Seq Scan</td> ❌</td></tr>
C</td> TextConcat</td> TextCol || Desc</code></td> 781ms</td> Seq Scan</td> ❌</td></tr>
D</strong></td> TextSingle</strong></td> TextCol</code></td> 0.01ms</strong></td> Bitmap Index Scan</strong></td> ✅</td></tr>
E</strong></td> Text OR</strong></td> TextCol OR Desc</code></td> 0.01ms</strong></td> BitmapOr</strong></td> ✅✅</td></tr>
F</td> CAST OR</td> LongCol::text OR Desc</code></td> 459ms</td> Seq Scan</td> ❌</td></tr>
</tbody></table>
Sadece D ve E GIN index kullanabiliyor. Neden?</p>
A, B, C:</strong> ||</code> concat ve ::text</code> CAST birer expression</em>. GIN index'i TextColumn</code> ve Description</code> sütunları üzerinde. Expression'lar bu index'lerle eşleşmez - planner Seq Scan'e düşer.</p>
D:</strong> TextColumn</code> direkt sütun referansı. ix_text_gin</code> tam bu sütunda. Planner anında Bitmap Index Scan kullanır.</p>
E:</strong> İki direkt sütun referansı, OR ile bağlı. PostgreSQL ix_text_gin</code> ve ix_desc_gin</code> index'lerini ayrı ayrı tarar, sonuçları BitmapOr</strong> ile birleştirir. Çift index, tek seferde.</p>
F:</strong> LongColumn::text</code> CAST'li, Description</code> direkt. CAST'li kısım index kullanamaz. PostgreSQL OR ifadesinin tamamını</em> Seq Scan'e düşürür - Description'ın GIN index'i olsa bile.</p>
Kritik Bulgu 2: E'nin EXPLAIN Planı - BitmapOr</h2>
Yaklaşım E (TextColumn OR Description</code>) GIN index ile şu planı üretiyor:</p>
Bitmap Heap Scan (time=0.003ms, rows=0)</span></span>
  -> BitmapOr</span></span>
    -> Bitmap Index Scan on ix_text_gin (time=0.003ms)</span></span>
       Index Cond: ("TextColumn" ~~ '%xyzqwerty%')</span></span>
    -> Bitmap Index Scan on ix_desc_gin (time=0.003ms)</span></span>
       Index Cond: ("Description" ~~ '%xyzqwerty%')</span></span></code></pre>
İki index paralel taranıyor, BitmapOr ile birleştiriliyor, heap'e hiç gidilmiyor. Sonuç: 0.01ms.</p>
Bu, ayrı ayrı LIKE + OR yaklaşımının concat'tan neden bu kadar üstün olduğunu gösteriyor. Concat (A, C) ifadeyi tek bir expression'a dönüştürüp index'i devre dışı bırakırken, OR her sütunu ayrı ayrı index'letebiliyor.</p>
Kritik Bulgu 3: CAST OR'u Zehirliyor</h2>
F (LongColumn::text OR Description</code>) GIN index varken bile Seq Scan:</p>
Gather (workers=2) -> Parallel Seq Scan</span></span>
  Filter: ((LongColumn::text ~~ '%xyzqwerty%') OR (Description ~~ '%xyzqwerty%'))</span></span>
  Rows Removed by Filter: 666,667 (x3 workers = 2M)</span></span>
  Execution Time: 459ms</span></span></code></pre>
Description'ın GIN index'i (ix_desc_gin</code>) var. Ama LongColumn::text</code> CAST'i non-indexable olduğu için, PostgreSQL tüm OR ifadesini Seq Scan olarak planlıyor. Tek bir non-indexable terim, tüm sorguyu index'siz bırakıyor.</p>
Bu, migration'ın neden kritik olduğunu gösteriyor: LongColumn</code> (bigint) durduğu sürece, ister concat ister OR kullan, index faydası alamazsın.</p>
Kritik Bulgu 4: Hız Sıralaması (GIN, seyrek pattern)</h2>
Kazananlar:</p>

D ve E: 0.01ms</strong> - index kullanıyor, sub-milisaniye</li>
B: 137ms</strong> - Seq Scan ama en kısa veri (14 byte)</li>
A: 468ms</strong> - Seq Scan, CAST + concat (~438 byte)</li>
F: 459ms</strong> - Seq Scan, CAST OR (~438 byte)</li>
C: 781ms</strong> - Seq Scan, TextConcat (~863 byte)</li>
</ol>
En yavaş C çünkü en büyük veriyi tarıyor (TextColumn 439B + Description 423B = 862B). En hızlı Seq Scan B çünkü sadece 14 byte'lık LongColumn::text taranıyor.</p>
Ama index devredeyken veri boyutunun önemi kalmıyor - D de 439 byte tarıyor olmasına rağmen index sayesinde 0.01ms.</p>
Diğer Bulgular</h2>
Sık pattern'lerde index kullanılmıyor.</strong> %de%</code> ve %ankara%</code> için tüm yaklaşımlar Seq Scan. Planner, çok satır match olunca heap lookup maliyetinin direkt taramayı geçtiğini biliyor.</p>
CAST maliyeti düşük.</strong> bigint::text</code> dönüşümü mikrosaniye seviyesinde. Asıl maliyet concat ile iki büyük sütunu birleştirmekte.</p>
A, C'den hızlı.</strong> CAST+concat (468ms), TextConcat'tan (781ms) daha hızlı. Sebep: LongColumn::text</code> 14 byte, TextColumn</code> 439 byte. CAST maliyeti değil, veri boyutu belirleyici.</p>
Pratik Tavsiyeler</h2>


LIKE sorgusunda asla concat kullanma.</strong> col1 || ' ' || col2</code> ifadesi sütun bazlı index'leri tamamen devre dışı bırakır. Her zaman ayrı ayrı LIKE + OR</strong> yap.</p>
</li>

OR kullanırken CAST'li sütunları OR'a dahil etme.</strong> Tek bir CAST'li terim bile olsa, tüm OR Seq Scan'e düşer. CAST'li sütunu ayrı bir WHERE koşulu olarak yazıp UNION</code> ile birleştirmek daha iyi olabilir.</p>
</li>

Non-text sütunları text'e çevir.</strong> bigint</code> gibi tiplerde LIKE araması yapıyorsan migration ile text sütuna taşı. CAST ortadan kalkar, GIN index kullanılabilir hale gelirsin.</p>
</li>

GIN trigram index'i seyrek pattern'ler için ezici.</strong> Ama sık pattern'lerde planner kullanmayacak. Index'in INSERT/UPDATE maliyetini değerlendir.</p>
</li>

Ayrı ayrı LIKE + OR, tek sütun LIKE kadar hızlı.</strong> E (TextColumn OR Description</code>) de D (TextColumn</code>) de 0.01ms. İkinci sütunu dahil etmenin index maliyeti yok denecek kadar az (BitmapOr).</p>
</li>

Kendi verinde ölç.</strong> Bu benchmark 2M satır, Docker macOS. EXPLAIN ANALYZE</code> ile kendi ortamında test et.</p>
</li>
</ol>
Kaynaklar</h2>

GitHub - pg-perf benchmark projesi</a></li>
PostgreSQL pg_trgm dokümantasyonu</a></li>
Npgsql EF Core - string çevirileri</a></li>
</ul>


.NET'te Bellek Yönetimi 1: Stack, Heap ve String'ler
2026-06-28T00:00:00+00:00
Selamlar. Bu hafta bir görüşme üzerine bellek yönetimi konusuna odaklanmam
gerektiğine karar verdim. Konuya dair yüzeysel bilgim vardı, derinleştirmek
istedim. Stack nedir, heap nedir, string neden heap'te yaşar, CLR bir obje
yarattığında arka planda neler döner, Span<T></code> bellek ayırmadan nasıl çalışır,
GC ne zaman devreye girer, IDisposable</code> kime yarar - hepsini sırayla
anlatacağım.</p>
Ama önce temelden başlayalım. "Stack ve heap" dediğimiz şey aslında ne?</p>
Veriye Yer Bulmak</h2>
Siz bir değişken tanımladığınızda:</p>
int</span> x</span> =</span> 5</span>;</span></span>
string</span> name</span> =</span> "</span>Erdinç</span>"</span>;</span></span>
User</span> user</span> =</span> new</span> User</span> {</span> Name</span> =</span> "</span>Erdinç</span>"</span>,</span> Age</span> =</span> 30</span> }</span>;</span></span></code></pre>
Bu x</code>, name</code> ve user</code> nerede duruyor? Bilgisayarınızın RAM'inde - tamam.
Peki RAM'in neresinde? Bir köşesinde mi, ortasında mı? Cevap: tipine göre.</strong></p>
.NET runtime'ı bellek yönetimi için iki ana bölge kullanır:</p>
Bölge</th> Açıklama</th></tr></thead>

Stack</strong></td> Metod çağrılarının, yerel değişkenlerin ve parametrelerin yaşadığı LIFO (Last-In-First-Out) yapı. Küçük, hızlı, otomatik temizlenir.</td></tr>
Heap</strong></td> Dinamik olarak ayrılan, uzun ömürlü nesnelerin yaşadığı bölge. Büyük, GC tarafından yönetilir.</td></tr>
</tbody></table>
İkisi arasındaki farkı anlamak, yazdığınız kodun performansını kavramanın
ilk adımıdır.</p>
Stack: LIFO Yapısı</h2>
Stack'in çalışma prensibini anlamak için en iyi örnek üst üste dizilmiş
tabaklardır.</strong> Bir tabak eklemek istediğinizde en üste koyarsınız. Bir tabak
almak istediğinizde en üsttekini alırsınız. Ortadan tabak çekemezsiniz.
En son koyduğunuz tabak, ilk alınan tabaktır. İşte bu LIFO'dur.</p>
[Tabak 3]  ← En son kondu, ilk alınır (Last-In)</span></span>
[Tabak 2]</span></span>
[Tabak 1]  ← İlk kondu, en son alınır (First-Out)</span></span></code></pre>
Stack'te olan da tam olarak budur. Metodlar üst üste binerek çalışır ve
biten metodun değişkenleri anında temizlenir:</p>
/*</span></span>
 * Calculate metodu bittiğinde içerideki tüm değişkenler (a, b, result)</span></span>
 * bellekten tamamen kaldırılır. Peki bu "kaldırma" işlemi tam olarak nedir?</span></span>
 *</span></span>
 * CPU seviyesinde stack, RSP (Stack Pointer) register'ı ile yönetilir.</span></span>
 * Metoda girerken RSP aşağı çekilir (sub rsp, N), böylece N byte'lık</span></span>
 * alan "tahsis edilmiş" olur. Metod dönerken RSP yukarı itilir</span></span>
 * (add rsp, N), bu alanı "serbest bırakır."</span></span>
 *</span></span>
 * Buna "Stack Pointer Adjustment" veya kısaca "stack unwinding" denir.</span></span>
 *</span></span>
 * Önemli nokta: serbest bırakılan bölgedeki veriler fiziksel olarak</span></span>
 * SİLİNMEZ. Sadece artık o bölge "kullanımda değil" olarak işaretlenir.</span></span>
 * İşletim sistemi bir sonraki metod çağrısında aynı bellek adreslerinin</span></span>
 * üzerine yeni değerler yazabilir. Bu yüzden C#'ta initialize edilmemiş</span></span>
 * bir yerel değişkeni okumaya çalışırsan derleyici hata verir,</span></span>
 * okuduğun değer bir önceki metodun çöp verisi olabilir.</span></span>
 */</span></span>
void</span> Calculate</span>(</span>)</span></span>
{</span></span>
    int</span> a</span> =</span> 10</span>;</span>       //</span> Stack'e a = 10 yazıldı</span></span>
    int</span> b</span> =</span> 20</span>;</span>       //</span> Stack'e b = 20 yazıldı</span></span>
    int</span> result</span> =</span> Add</span>(</span>a</span>,</span> b</span>)</span>;</span>  //</span> Add metodu çağrıldı</span></span>
}</span>   //</span> Calculate dönünce RSP yukarı çekilir, frame serbest kalır</span></span>
</span>
int</span> Add</span>(</span>int</span> x</span>,</span> int</span> y</span>)</span></span>
{</span></span>
    int</span> sum</span> =</span> x</span> +</span> y</span>;</span>  //</span> Stack'te x, y, sum için yeni frame açıldı</span></span>
    return</span> sum</span>;</span>       //</span> Add dönünce kendi frame'i serbest kalır</span></span>
}</span></span></code></pre>
Metod çağrıldıkça stack büyür, metod döndükçe stack küçülür. Her metod kendi
stack frame</strong>'ini oluşturur. Frame, o metodun parametrelerini, yerel
değişkenlerini ve dönüş adresini içerir. Görsel olarak:</p>
flowchart TB
    subgraph T1["1. Calculate çağrıldı"]
        direction LR
        A1["[Boş]"]
    end
    subgraph T2["2. int a = 10"]
        direction LR
        A2["a = 10"]
    end
    subgraph T3["3. int b = 20"]
        direction LR
        A3["b = 20"]
        A3b["a = 10"]
    end
    subgraph T4["4. Add(10, 20) çağrıldı"]
        direction LR
        A4["sum = 30"]
        A4b["y = 20"]
        A4c["x = 10"]
        A4d["--- frame sınırı ---"]
        A4e["b = 20"]
        A4f["a = 10"]
    end
    subgraph T5["5. Add döndü (frame silindi)"]
        direction LR
        A5["result = 30"]
        A5b["b = 20"]
        A5c["a = 10"]
    end
    subgraph T6["6. Calculate döndü (hepsi silindi)"]
        direction LR
        A6["[Boş]"]
    end

    T1 --> T2 --> T3 --> T4 --> T5 --> T6
</pre>
Dikkat edin: Add metodu döndüğünde x</code>, y</code>, sum</code> - frame ile birlikte
hemen</strong> silindi. GC'nin gelmesini beklemedik. Buna deterministik
temizleme</strong> denir.</p>
Çöp Değer ve Bellek Güvenliği</h2>
Yukarıda dedik ki: serbest bırakılan stack bölgesindeki veriler fiziksel
olarak silinmez. Peki bu "silinmemiş" veriye erişmeye kalksak ne olur?</p>
C++ Tarafı: Adres Ver, İstediğin Yere Git</h3>
C++ bu konuda hiçbir engel koymaz. Stack'te bir değişken tanımlar,
initialize etmez ve okumaya kalkarsanız:</p>
void</span> Foo</span>(</span>)</span></span>
{</span></span>
    int</span> previousData </span>=</span> 42</span>;</span>    //</span> stack'te bir değer bıraktı</span></span>
}</span></span>
</span>
void</span> Bar</span>(</span>)</span></span>
{</span></span>
    int</span> x</span>;</span>                    //</span> initialize edilmedi!</span></span>
    std</span>::</span>cout </span><<</span> x</span>;</span>           //</span> 42 veya başka rastgele bir sayı basar</span></span>
}</span></span></code></pre>
Bar</code> çağrıldığında stack frame'i Foo</code>'nun bıraktığı bölgeye denk
gelebilir. x</code>'in değeri 42</code> olur - ama bu tamamen tesadüftür. Başka
bir çalışma sırasında bambaşka bir sayı alırsınız. Buna undefined
behavior</strong> denir. Derleyici hata vermez, çalışma zamanında patlamazsınız;
yanlış sonuç alırsınız, haberiniz bile olmaz.</p>
Daha da kötüsü, C++ pointer aritmetiği ile stack'in tamamen dışına çıkıp
aynı process içindeki bambaşka bir veriye erişebilirsiniz:</p>
int</span> arr</span>[</span>3</span>]</span> =</span> {</span>1</span>,</span> 2</span>,</span> 3</span>}</span>;</span></span>
int</span>*</span> p </span>=</span> arr</span>;</span></span>
p </span>+=</span> 100</span>;</span>                //</span> dizinin 100 eleman ötesi - tanımsız bölge</span></span>
std</span>::</span>cout </span><<</span> *</span>p</span>;</span>         //</span> orada ne varsa onu okur</span></span></code></pre>
Modern işletim sistemlerinde sanal bellek (virtual memory) sayesinde başka
bir programın</strong> belleğine erişemezsiniz - MMU buna izin vermez, segfault
yersiniz. Ama kendi process'iniz içinde istediğiniz adrese gidip okuyabilirsiniz.</p>
C# Tarafı: Derleyici Engel Koyar</h3>
C# bu konuda C++'ın tam tersidir. C# bellek hareketleri güvenlidir.</strong>
Aynı senaryoyu C#'ta deneyelim:</p>
void</span> Bar</span>(</span>)</span></span>
{</span></span>
    int</span> x</span>;</span></span>
    Console</span>.</span>WriteLine</span>(</span>x</span>)</span>;</span>  //</span> DERLEME HATASI: Use of unassigned local variable 'x'</span></span>
}</span></span></code></pre>
C# derleyicisi definite assignment</strong> analizi yapar. Yerel bir değişkenin
okunmadan önce mutlaka bir değer atanmış olmasını zorunlu tutar. Atanmamışsa
derleme aşamasında hata alırsınız - çalışma zamanına bile gelemez.</p>
Sebebi basit: initialize edilmemiş bir
değişkeni okumak, bellekte o anda ne varsa onu almanız demektir. Orada
rastgele bir değer vardır ve bu değer programınızın mantığını bozabilir.</p>
Bir hastane yazılımı düşünün:</p>
//</span> C#'ta bu kod derlenmez - ama derlendiğini varsayalım</span></span>
int</span> insulinDose</span>;</span>                  //</span> atanmadı!</span></span>
AdministerInsulin</span>(</span>patient</span>,</span> insulinDose</span>)</span>;</span>  //</span> rastgele bir doz uygulanır</span></span></code></pre>
Eğer insulinDose</code> bellekte kalan bir önceki değeri (diyelim ki 999)
okursa, hasta ölebilir. C# tam olarak bu senaryoyu önlemek için "kullanmadan
önce ata" kuralını koyar. C++ ise böyle bir koruma sunmaz - hata sessizce
çalışmaya devam eder.</p>
C#'ın unsafe</code> bağlamında pointer kullanabilirsiniz, ama bu kasıtlı bir
tercihtir ve /unsafe</code> derleme bayrağı gerektirir. Normal C# kodunda
yanlışlıkla initialize edilmemiş bir değeri okuyamazsınız.</p>
Özet: Neden C# Engel Koyar?</h3>
Durum</th> C++</th> C#</th></tr></thead>

Initialize edilmemiş yerel değişken okuma</td> Derlenir, rastgele değer döner (undefined behavior)</td> Derleme hatası (CS0165)</td></tr>
Pointer ile stack dışına çıkma</td> Derlenir, segfault veya rastgele veri</td> unsafe</code> olmadan yapamazsınız</td></tr>
Dizi sınırlarını aşma</td> Derlenir, undefined behavior</td> IndexOutOfRangeException</code> fırlatır</td></tr>
Null referans kullanma</td> Derlenir, segfault</td> NullReferenceException</code> fırlatır</td></tr>
</tbody></table>
C# runtime'ı sizi korumak için ekstra kontroller yapar. Bu kontrollerin
bir performans maliyeti vardır (array bounds check gibi), ama güvenlik
ve hata ayıklama kolaylığı açısından buna değer.</p>
Stack'in özellikleri:</p>

Boyut:</strong> Thread başına 1-8 MB. stackalloc</code> yapmadığınız sürece dolmaz.</li>
Hız:</strong> Allocation ve deallocation tek CPU komutu (stack pointer hareketi). Cache-friendly.</li>
Ömür:</strong> Metod scope'u ile sınırlı. Metod bitince değişken ölür.</li>
Ne yaşar:</strong> int</code>, bool</code>, double</code>, struct</code>, enum</code> gibi value type'lar. Ayrıca reference type'ların referansları</strong> (adresleri).</li>
</ul>
Stack'in en kritik kuralı: boyutu derleme zamanında bilinmeyen hiçbir şey
stack'te yaşayamaz.</strong> Bir metod çağrısında stack frame'in boyutu önceden
hesaplanmak zorundadır.</p>
Bu yüzden:</p>
byte</span>[</span>]</span> buffer</span> =</span> new</span> byte</span>[</span>4096</span>]</span>;</span>  //</span> buffer referansı (8 byte) stack'te, 4096 byte heap'te</span></span></code></pre>
buffer</code> değişkeni (8 byte'lık bir adres) stack'tedir. Ama işaret ettiği
4096 byte'lık alan heap'tedir. Çünkü o 4096 byte'ın ömrü metod bitince sona
ermeyebilir - başkası hala kullanıyor olabilir.</p>
Array'in Heap'teki Gerçek Yapısı</h3>
Peki byte[4096]</code> heap'te tam olarak nasıl duruyor? Ve CLR, buffer[150]</code>
dediğinizde 150. byte'ı nasıl buluyor? Sınırı nereden biliyor? Hadi
parçalayalım.</p>
Heap'te bir dizi objesinin yapısı:</p>
flowchart LR
    subgraph Stack["Stack"]
        U["buffer = 0x00E100 (heap'teki byte[] objesinin başlangıç adresi)"]
    end
    subgraph Heap["Heap"]
        direction TB
        subgraph Arr["byte[] objesi (adres: 0x00E100)"]
            direction LR
            A1["MethodTable* (0x00A000) (8 byte, Byte[] MethodTable'ının adresi)"]
            A2["Length = 4096 (4 byte)"]
            A3["padding (4 byte)"]
            A4["[0] = 0 (1 byte)"]
            A5["[1] = 0 (1 byte)"]
            A6["... (4094 byte)"]
            A7["[4095] = 0 (1 byte)"]
        end
        subgraph MT["Byte[] MethodTable (0x00A000)"]
            direction LR
            M1["BaseSize: 16"]
            M2["ComponentSize: 1"]
            M3["ElementType: System.Byte"]
            M4["Rank: 1"]
            M5["IsArray: true"]
        end
    end
    U -.->|"heap'teki adresi tutar"| Arr
    A1 -.->|"MethodTable'ın adresini tutar"| MT
</pre>
MethodTable* (8 byte): Bu, Byte[] tipine ait MethodTable'ın heap'teki
adresidir.</strong> Yani 0x00A000</code> gibi bir bellek adresidir. CLR bu adresi
okuyarak objenin hangi tipe ait olduğunu, elemanlarının boyutunu, sınırlarını
ve davranışlarını (method'larını) öğrenir. Her tip için bir tane MethodTable
vardır ve o tipteki bütün objeler aynı MethodTable'ı paylaşır.</p>
Dikkat edin: stack'teki buffer</code> değişkeni 0x00E100</code> değerini tutar.
Bu değer, heap'teki byte[] objesinin başlangıç adresidir.</strong> Başka bir
deyişle buffer</code>, heap'teki 4096 byte'lık alanın "adres kartıdır."
Bu referansı elinize aldığınızda CLR şunları yapabilir:</p>
1. Tipi öğrenmek:</strong> buffer.GetType()</code> → önce buffer</code>'ın tuttuğu
0x00E100 adresine gider, oradaki 8 byte'lık MethodTable* değerini (0x00A000)
okur. 0x00A000, Byte[] MethodTable'ının adresidir. O MethodTable'dan
IsArray = true</code>, ElementType = System.Byte</code>, Rank = 1</code> bilgilerine ulaşır.</p>
2. Uzunluğu öğrenmek:</strong> buffer.Length</code> → 0x00E100 + 8. byte'taki
4 byte'lık Length</code> değerini okur. 4096.</p>
3. Elemana erişmek:</strong> buffer[150]</code> dediğinizde CLR üç kontrollü adım atar:</p>
1. Sınır kontrolü:   if (150 < 0 || 150 >= 4096) → throw IndexOutOfRangeException</span></span>
2. Adres hesabı:      hedef = 0x00E100 + 16 (header) + (150 × 1) (componentSize)</span></span>
                      = 0x00E100 + 16 + 150</span></span>
                      = 0x00E196</span></span>
3. Okuma/Yazma:       *(byte*)0x00E196</span></span></code></pre>
Formülün parçaları:</p>
Parça</th> Değer</th> Kaynak</th></tr></thead>

Base adres</strong></td> 0x00E100</code></td> Stack'teki buffer</code> referansı</td></tr>
Header boyutu</strong></td> 16 byte</code> (8 MT + 4 Length + 4 padding)</td> Array MethodTable'daki BaseSize</code></td></tr>
ComponentSize</strong></td> 1</code> (byte için)</td> Array MethodTable'daki ComponentSize</code> alanı</td></tr>
Length</strong></td> 4096</code></td> Objenin 8. byte offset'inde</td></tr>
index</strong></td> 150</code></td> Sizin yazdığınız kod</td></tr>
</tbody></table>
MethodTable'da diziler için iki özel alan daha vardır:</p>

ComponentSize</code>:</strong> Her bir elemanın byte cinsinden boyutu. byte[]</code> için 1,
int[]</code> için 4, bir struct</code> dizisi için struct'ın boyutu.</li>
BaseSize</code>:</strong> Dizinin header kısmının boyutu (MT + Length + padding).
Gerçek obje boyutu = BaseSize + (Length × ComponentSize)</code>.</li>
</ul>
CLR, buffer[150]</code> için gereken her şeyi MethodTable + Length ikilisinden
çıkarır. Ayrı bir "start/length" struct'ına ihtiyaç duymaz, çünkü dizi
her zaman 0. indexten başlar. start</code> her zaman 0'dır.</p>
Span<T>'de Start/Length Durumu</h3>
"Start ve length değerlerine sahip struct tipi" dediğiniz şey aslında
Span<T></code>'dir. Span, bir dizinin üzerinde</strong> çalışan bir view (görünüm)
struct'ıdır:</p>
byte</span>[</span>]</span> fullBuffer</span> =</span> new</span> byte</span>[</span>4096</span>]</span>;</span></span>
Span</span><</span>byte</span>></span> slice</span> =</span> fullBuffer</span>.</span>AsSpan</span>(</span>100</span>,</span> 50</span>)</span>;</span>  //</span> 100. byte'tan başla, 50 byte al</span></span></code></pre>
Span'in kendisi stack'te yaşayan bir struct'tır (value type) ve içinde şunlar
vardır:</p>
flowchart LR
    subgraph Stack["Stack"]
        direction TB
        subgraph Span["Span<byte> slice (stack)"]
            S1["_reference (8 byte, 100. elemanın heap adresini tutar)"]
            S2["_length = 50 (4 byte)"]
        end
    end
    subgraph Heap["Heap"]
        direction TB
        subgraph Arr["byte[] fullBuffer (0x00E100)"]
            direction LR
            MT["MethodTable* (8)"]
            LEN["Length = 4096 (4)"]
            PAD["padding (4)"]
            EL0["[0]...[99] (100 byte, header + 0..99)"]
            EL100["[100] = slice başlangıcı"]
            EL149["[149] = slice sonu"]
            EL150["[150]...[4095]"]
        end
    end
    S1 -.->|"header'ı atlayıp doğrudan 100. elemanı gösterir"| EL100
</pre>
Span'in _reference</code> alanı, dizinin başlangıcını değil, dilimin başlangıcını</strong>
işaret eder (offset eklenmiş hali). Span üzerinde indeksleme yaparken CLR:</p>
1. Dizi sınırı:       if (index < 0 || index >= 50) → hata (Span'in _length'i)</span></span>
2. Gerçek adres:      hedef = _reference + (index × 1)</span></span></code></pre>
Gördüğünüz gibi Span, "start ve length" bilgisini taşır. Ama byte[]</code>'in
kendisi taşımaz, dizi her zaman 0'dan başlar, length ise objenin içinde
gömülüdür. Start/length ikilisi bir view ihtiyacı olduğunda devreye girer.</p>
Eleman Tipi Nereden Biliniyor?</h3>
buffer[150]</code> okurken CLR, 150. byte'ın bir byte</code> olduğunu ComponentSize</strong>
değerinden anlar. Byte[]</code> MethodTable'ında ComponentSize = 1</code> yazar.
Int32[]</code> için 4, Double[]</code> için 8.</p>
Peki eleman bir reference type ise? string[]</code> düşünelim:</p>
string</span>[</span>]</span> names</span> =</span> new</span> string</span>[</span>3</span>]</span>;</span></span></code></pre>
Bu dizinin heap'teki yapısı:</p>
[MethodTable* → String[]]    (8 byte)</span></span>
[Length = 3]                 (4 byte)</span></span>
[padding]                    (4 byte)</span></span>
[names[0] = null]            (8 byte - string referansı)</span></span>
[names[1] = null]            (8 byte - string referansı)</span></span>
[names[2] = null]            (8 byte - string referansı)</span></span>
Toplam: 16 + (3 × 8) = 40 byte</span></span></code></pre>
Burada ComponentSize = 8</code> (64-bit'te referans boyutu). Her eleman bir
referanstır, string'in kendisi heap'te başka bir yerdedir. Dizi sadece
adresleri tutar. names[1]</code> okurken:</p>
1. Adres:    0x00E100 + 16 + (1 × 8) = 0x00E118</span></span>
2. Oku:      *(string*)0x00E118 → 0x00F200 (string'in adresi)</span></span>
3. String'e git: 0x00F200'deki string objesini oku</span></span></code></pre>
GC de bu referansları takip eder. string[]</code> dizisinin kendisi hayatta olduğu
sürece, dizinin içindeki string referanslarının gösterdiği string'ler de
hayatta kalır (başka hiçbir yer referans vermiyor olsa bile).</p>
Heap ve MethodTable</h2>
Heap'i büyük bir arsa</strong> gibi düşünün. İhtiyacınız olduğunda bir parsel
ayırırsınız (allocation), işiniz bitince boşaltırsınız (GC toplar). Stack'in
aksine burada sıra yoktur - her parsel bağımsızdır.</p>
Ama asıl mesele, heap'te bir obje yaratıldığında CLR'ın perde arkasında
neler yaptığıdır. new User()</code> dediğiniz anda olanları adım adım inceleyelim.</p>
CLR Obje Yaratırken Ne Olur?</h3>
var</span> user</span> =</span> new</span> User</span> {</span> Name</span> =</span> "</span>Erdinç</span>"</span>,</span> Age</span> =</span> 30</span> }</span>;</span></span></code></pre>
Bu satır çalıştığında CLR şu adımları izler:</p>


Tip bilgisine bak.</strong> CLR, User</code> tipini tanıyor mu? User</code> sınıfına ait
MethodTable</code> nerede? (Eğer ilk kez kullanılıyorsa tip yüklenir - type load.)</p>
</li>

Bellek ayır.</strong> MethodTable</code>'daki BaseSize</code> alanına bakar. Bu alan,
User</code> tipindeki bir objenin heap'te kaç byte yer kaplayacağını söyler.
GC heap'inden bu kadar byte'lık alan tahsis edilir.</p>
</li>

MethodTable işaretçisini yaz.</strong> Ayrılan belleğin ilk 8 byte'ına (64-bit)
veya 4 byte'ına (32-bit) MethodTable</code>'ın adresi yazılır. Bu işaretçi
(TypeHandle), objenin hangi tipe ait olduğunu çalışma zamanında
söyleyen kritik bir referanstır.</p>
</li>

Field'ları sıfırla.</strong> Kalan alan sıfırlanır. int</code> → 0, string</code> → null,
bool</code> → false.</p>
</li>

Constructor'ı çağır.</strong> User</code>'ın constructor'ı çalışır, field'lara
gerçek değerleri yazar.</p>
</li>

Referansı döndür.</strong> var user</code> değişkenine, heap'te ayrılan bu objenin
başlangıç adresi</strong> atanır. Bu adres stack'te tutulur.</p>
</li>
</ol>
Görsel olarak:</p>
flowchart LR
    subgraph Stack["Stack"]
        direction TB
        U["user = 0x001A3F (8 byte)"]
    end

    subgraph Heap["Heap"]
        direction TB
        subgraph Obj["User objesi (adres: 0x001A3F)"]
            direction LR
            MT["MethodTable* (8 byte)"]
            F1["Age = 30 (4 byte)"]
            PAD["padding (4 byte)"]
            F2["Name = 0x00B210 (8 byte)"]
        end
        subgraph MTBlock["User MethodTable"]
            direction LR
            MTInfo["BaseSize: 24
            EEClass*: 0xF0A100
            Parent MethodTable*: System.Object
            Interface count: 0
            Method slots: ..."]
        end
        subgraph Str["String 'Erdinç' (0x00B210)"]
            direction LR
            SM["MethodTable* (System.String)"]
            SL["Length = 6"]
            SC["chars: E r d i n ç"]
        end
    end

    U -.->|"işaret eder"| Obj
    MT -.->|"tip bilgisi"| MTBlock
    F2 -.->|"Name işaret eder"| Str
</pre>
MethodTable Nedir, Ne İşe Yarar?</h3>
Her tipin bir MethodTable</strong>'ı vardır. CLR, bu tabloyu tip ilk
yüklendiğinde oluşturur ve o tipin tüm objeleri aynı MethodTable'ı paylaşır.
Yani milyon tane User</code> objesi yaratsanız da tek bir</strong> User</code> MethodTable'ı
vardır.</p>
MethodTable'ın içeriği (basitleştirilmiş):</p>
Alan</th> Açıklama</th></tr></thead>

BaseSize</strong></td> Bu tipteki bir objenin heap'te kaç byte yer kaplayacağı. GC'nin allocation için kullandığı ilk alan.</td></tr>
EEClass pointer</strong></td> EEClass</code> yapısına işaret eder. Field'ların offset'leri, interface listesi, property metadata'ları buradadır.</td></tr>
Parent MethodTable</strong></td> Kalıtım zinciri. User</code> ise parent'ı System.Object</code>'in MethodTable'ıdır.</td></tr>
Interface count ve Interface map</strong></td> Hangi interface'leri implement ettiği. Cast ve is</code> kontrolü için kullanılır.</td></tr>
Method slots</strong></td> Virtual method'ların adresleri. ToString()</code>, GetHashCode()</code> gibi.</td></tr>
</tbody></table>
Yani user.GetType()</code> dediğinizde CLR'ın yaptığı tek şey, objenin ilk
8 byte'ındaki MethodTable işaretçisini okuyup size ilgili Type</code> nesnesini
döndürmektir.</p>
Namespace ile MethodTable İlişkisi</h3>
MethodTable, namespace'lere göre değil</strong>, tip başına</strong> oluşturulur.
Namespace dediğimiz şey derleme zamanında kullanılan mantıksal bir
gruplandırmadır. Runtime'ta "namespace MethodTable" diye bir yapı yoktur.</p>
Bir tipin runtime'taki tam kimliği üç parçadan oluşur:</p>
Assembly + Namespace + TypeName</span></span></code></pre>
Örneğin:</p>
namespace</span> MyApp</span>.</span>Models</span></span>
{</span></span>
    public</span> class</span> User</span> {</span> ... </span>}</span>     //</span> Kimlik: MyApp.dll + MyApp.Models + User</span></span>
}</span></span>
</span>
namespace</span> MyApp</span>.</span>DTOs</span></span>
{</span></span>
    public</span> class</span> User</span> {</span> ... </span>}</span>     //</span> Kimlik: MyApp.dll + MyApp.DTOs + User</span></span>
}</span></span></code></pre>
Bu iki User</code> sınıfının isimleri aynı olsa da, namespace'leri farklıdır.
Dolayısıyla CLR bunlar için iki ayrı MethodTable</strong> oluşturur. Her birinin
kendi BaseSize</code>, field offset'leri ve method slot'ları vardır. Models.User</code>
ile DTOs.User</code> tamamen farklı iki tiptir, sadece isim benzerliği vardır.</p>
Namespace bilgisi MethodTable'ın içinde ayrı bir alan olarak değil, tipin
adının bir parçası</strong> olarak tutulur. Type.FullName</code> dediğinizde
"MyApp.Models.User"</code> döner; bu string, tipin metadata'sından gelir. CLR
bir tipi yüklerken bu tam ismi kullanır:</p>
1. assembly'de "MyApp.Models.User" diye bir tip var mı?</span></span>
2. Varsa, onun MethodTable'ını yükle (veya zaten yüklüyse onu kullan)</span></span>
3. Yoksa TypeLoadException fırlat</span></span></code></pre>
Yani namespace, tip çözümleme (type resolution) için gereklidir ama
MethodTable'ın kendisi namespace bazlı değil, tip bazlıdır. Aynı namespace
içindeki 50 sınıf = 50 ayrı MethodTable.</p>
Property'lere Erişim: Offset Mekanizması</h3>
Peki user.Name</code> dediğinizde CLR, heap'teki objenin hangi byte'larının
Name</code> property'sine ait olduğunu nasıl bilir? Cevap: field offset.</strong></p>
EEClass</code> içinde her field için bir offset değeri tutulur:</p>
User Class EEClass (basitleştirilmiş):</span></span>
  Field: Age      → offset: 8   (MethodTable işaretçisinden hemen sonra)</span></span>
  Field: Name     → offset: 16  (Age 4 byte + padding 4 byte = 8 byte sonra)</span></span>
  Total size      → 24 byte     (8 MT + 4 Age + 4 pad + 8 Name)</span></span></code></pre>
Peki padding neden var? CPU, bellekteki verilere daha hızlı erişmek için
hizalama (alignment)</strong> ister. 64-bit sistemde 8 byte'lık referanslar
8'in katı olan adreslerde durmalıdır. Bu yüzden Age</code> (4 byte) ile Name</code>
(8 byte) arasına 4 byte padding konur.</p>
CLR bu offset değerlerini kullanarak user.Name</code> çağrısını şuna dönüştürür:</p>
//</span> user.Name aslında şudur:</span></span>
string</span> name</span> =</span> *</span>(</span>string</span>*</span>)</span>(</span>(</span>byte</span>*</span>)</span>user</span> +</span> 16</span>)</span>;</span>  //</span> objenin 16. byte'ındaki referansı oku</span></span></code></pre>
Offset ile erişimin avantajı:</strong> Her obje için ayrı bir property adresi
haritası tutulmaz. Tüm User</code> objeleri aynı offset'leri kullanır. Sadece
base address değişir: objenin_adresi + Age_offset = Age'in adresi</code>.</p>
Dikkat edin: Age</code> value type olduğu için değerin kendisi heap'teki objenin
içindedir.</strong> Ama Name</code> reference type olduğu için heap'teki objenin
içinde sadece adresi</strong> vardır. Asıl string verisi başka bir heap adresindedir.</p>
Kalıtımda Offset Durumu</h3>
class</span> Person</span></span>
{</span></span>
    public</span> int</span> Id</span> {</span> get</span>;</span> set</span>;</span> }</span></span>
}</span></span>
</span>
class</span> User</span> :</span> Person</span></span>
{</span></span>
    public</span> string</span> Name</span> {</span> get</span>;</span> set</span>;</span> }</span></span>
    public</span> int</span> Age</span> {</span> get</span>;</span> set</span>;</span> }</span></span>
}</span></span></code></pre>
Heap'teki User</code> objesi:</p>
[MethodTable* → User]  (8 byte, en başta)</span></span>
[Id: int]              (offset 8, Person'dan gelen field)</span></span>
[Name: string ref]     (offset 16, 4 byte Id + 4 padding = 8)</span></span>
[Age: int]             (offset 24)</span></span>
Toplam: 32 byte</span></span></code></pre>
Burada kritik nokta: parent class'ın field'ları her zaman child'ın
field'larından önce</strong> gelir. Bu sayede Person person = user;</code> yaptığınızda
bile person.Id</code> aynı offset'ten okunur. Çünkü Person</code> MethodTable'ı da
Id</code>'nin 8. byte'ta olduğunu bilir - ve user</code> objesinin 8. byte'ında
gerçekten de Id</code> durur.</p>
Value Type vs Reference Type: Özet Tablo</h2>
Özellik</th> Value Type (struct</code>, int</code>, bool</code>)</th> Reference Type (class</code>, string</code>)</th></tr></thead>

Yaşadığı yer</strong></td> Sahibinin bulunduğu yer (stack veya heap içinde)</td> Her zaman heap</td></tr>
Atama davranışı</strong></td> Değer kopyalanır</td> Referans (adres) kopyalanır</td></tr>
Null olabilir mi?</strong></td> Hayır (int?</code> nullable wrapper ile evet)</td> Evet</td></tr>
Varsayılan değer</strong></td> Sıfırlanmış hali (0</code>, false</code>, default</code>)</td> null</code></td></tr>
Kalıtım</strong></td> System.ValueType</code>'tan, sealed</td> Object</code>'ten</td></tr>
GC etkisi</strong></td> Sahibi toplanınca otomatik gider</td> GC toplaması gerekir</td></tr>
Objede nasıl durur?</strong></td> Değer objenin içindedir</td> Adres objenin içindedir</td></tr>
</tbody></table>
String Meselesi</h2>
String bu hikayede özel bir yere sahip. Kafaları en çok karıştıran tip.</p>
string</span> a</span> =</span> "</span>hello</span>"</span>;</span></span>
string</span> b</span> =</span> a</span>;</span></span>
b</span> =</span> "</span>world</span>"</span>;</span></span>
//</span> a hala "hello", değil mi? Evet.</span></span></code></pre>
String reference type'tır - heap'tedir. Ama immutable'dır</strong> (değiştirilemez).
Bu yüzden yukarıdaki b = "world"</code> işlemi a</code>'yı etkilemez, çünkü b</code>'nin
işaret ettiği string'in içeriğini değiştirmez - b</code>'ye yeni bir string'in
adresini atar.</p>
Aslında string'in heap'teki yapısı da MethodTable ile başlar:</p>
String objesi (heap):</span></span>
  [MethodTable* → System.String]  (8 byte)</span></span>
  [Length: int = 5]               (4 byte)</span></span>
  [Padding]                       (4 byte)</span></span>
  [First Char: 'h']               (2 byte)</span></span>
  [Second Char: 'e']              (2 byte)</span></span>
  ...</span></span></code></pre>
Length</code> ve karakterler objenin içinde, sabit offset'lerle erişilebilir.
Ama içeriği değiştiremezsiniz</strong> çünkü CLR string'in yazılabilir olduğunu
bilmez - obje readonly olarak işaretlenmiştir.</p>
Neden Immutable?</h3>

Thread safety.</strong> Birden fazla thread korksuzca aynı string'i okuyabilir.</li>
Interning.</strong> Aynı içerikteki string'ler bellekte bir kez tutulur.</li>
Güvenlik.</strong> Bir string'i metoda parametre geçtiniz diye metod onu
değiştiremez.</li>
</ol>
Ama bu immutability'nin bir bedeli var:</p>
string</span> result</span> =</span> "</span>"</span>;</span></span>
for</span> (</span>int</span> i</span> =</span> 0</span>;</span> i</span> <</span> 10000</span>;</span> i</span>++</span>)</span></span>
{</span></span>
    result</span> +=</span> "</span>x</span>"</span>;</span>   //</span> Her döngüde yeni string objesi. 10.000 allocation.</span></span>
}</span></span></code></pre>
Bu kod 10.000 defa yeni string</code> objesi yaratır, heap'i kirletir. Doğrusu:</p>
var</span> sb</span> =</span> new</span> StringBuilder</span>(</span>)</span>;</span></span>
for</span> (</span>int</span> i</span> =</span> 0</span>;</span> i</span> <</span> 10000</span>;</span> i</span>++</span>)</span></span>
{</span></span>
    sb</span>.</span>Append</span>(</span>"</span>x</span>"</span>)</span>;</span></span>
}</span></span>
string</span> result</span> =</span> sb</span>.</span>ToString</span>(</span>)</span>;</span>  //</span> Tek allocation.</span></span></code></pre>
String, reference type olmasına rağmen value type gibi davranır. ==</code>
operatörü içerik karşılaştırır (adres değil). Immutable olduğu için kopyalama
güvenlidir. Ama bellekte hep heap'tedir</strong> - stack'te yaşayamaz, çünkü
boyutu derleme zamanında bilinmez ve ömrü metod scope'unu aşabilir.</p>
String Interning</h3>
CLR sık kullanılan string'leri intern pool</strong> denen bir havuzda tutar:</p>
string</span> a</span> =</span> "</span>dotnet</span>"</span>;</span></span>
string</span> b</span> =</span> "</span>dotnet</span>"</span>;</span></span>
Console</span>.</span>WriteLine</span>(</span>Object</span>.</span>ReferenceEquals</span>(</span>a</span>,</span> b</span>)</span>)</span>;</span> //</span> True - aynı obje.</span></span></code></pre>
Derleme zamanında sabit olan string'ler otomatik intern edilir. Runtime'da
manuel de yapabilirsiniz:</p>
string</span> c</span> =</span> new</span> string</span>(</span>new</span> char</span>[</span>]</span> {</span> '</span>d</span>'</span>,</span> '</span>o</span>'</span>,</span> '</span>t</span>'</span>,</span> '</span>n</span>'</span>,</span> '</span>e</span>'</span>,</span> '</span>t</span>'</span> }</span>)</span>;</span></span>
string</span> d</span> =</span> string</span>.</span>Intern</span>(</span>c</span>)</span>;</span></span></code></pre>
Peki bir metod runtime'da string döndüğünde intern otomatik gerçekleşir mi?
İki senaryo var:</p>
Senaryo A: Metod compile-time literal dönerse - intern edilir.</strong></p>
string</span> GetHelloWorld</span>(</span>)</span></span>
{</span></span>
    return</span> "</span>Merhaba dunya</span>"</span>;</span>   //</span> compile-time literal</span></span>
}</span></span>
</span>
string</span> a</span> =</span> "</span>Merhaba dunya</span>"</span>;</span></span>
string</span> b</span> =</span> GetHelloWorld</span>(</span>)</span>;</span></span>
</span>
Object</span>.</span>ReferenceEquals</span>(</span>a</span>,</span> b</span>)</span>;</span> //</span> True - ikisi de aynı intern objesi</span></span></code></pre>
GetHelloWorld()</code> gövdesindeki "Merhaba dunya"</code> literal'ı assembly
metadata'sına gömülür. CLR assembly yüklerken onu da intern havuzuna atar.
Metod çağrıldığında havuzdaki aynı objeyi döner. İki literal +</code> ile
birleşiyorsa derleyici build time'da optimize edip tek literal'a
indirgeyebiliyorsa, sonuç yine intern olur.</p>
Senaryo B: Metod string'i runtime'da oluşturursa - intern edilmez.</strong></p>
string</span> GetHelloWorld</span>(</span>)</span></span>
{</span></span>
    var</span> merhaba</span> =</span> "</span>Merhaba </span>"</span>;</span></span>
    var</span> dunya</span> =</span> "</span>dunya</span>"</span>;</span></span>
    return</span> merhaba</span> +</span> dunya</span>;</span>   //</span> runtime concat, yeni obje</span></span>
}</span></span>
</span>
string</span> a</span> =</span> "</span>Merhaba dunya</span>"</span>;</span></span>
string</span> b</span> =</span> GetHelloWorld</span>(</span>)</span>;</span></span>
</span>
Object</span>.</span>ReferenceEquals</span>(</span>a</span>,</span> b</span>)</span>;</span> //</span> False - b runtime'da oluştu, intern havuzunda değil</span></span>
</span>
string</span> c</span> =</span> string</span>.</span>Intern</span>(</span>b</span>)</span>;</span>  //</span> Manuel intern</span></span>
Object</span>.</span>ReferenceEquals</span>(</span>a</span>,</span> c</span>)</span>;</span> //</span> True - artık aynı havuz objesi</span></span></code></pre>
Değişkenlerle +</code> concat, StringBuilder.ToString()</code>, Substring()</code>,
ToUpper()</code>, dosyadan okuma, JSON deserialize - bunların hepsi runtime'da
yeni heap objesi yaratır. İçerik aynı olsa bile intern havuzuna kendiliğinden
girmez. string.Intern()</code> çağırmanız gerekir.</p>
Özetle mesele string'in içeriği değil</strong>, nasıl oluştuğudur.</strong> Dahasına
sonra bakacağız.</p>
Interning sayesinde aynı string defalarca heap'te yer kaplamaz. Ama aşırı
kullanımı GC'nin Gen 2'sini şişirebilir - çünkü intern edilen string'ler
asla</strong> GC tarafından toplanmaz (AppDomain kapanana kadar yaşar).</p>
Özet: Stack, Heap, MethodTable İlişkisi</h2>
Bir new User()</code> çağrısının baştan sona yolculuğu:</p>
1. CLR, User MethodTable'ına bakar → BaseSize: 24 byte</span></span>
2. GC heap'inden 24 byte ayırır</span></span>
3. Ayrılan alanın ilk 8 byte'ına User MethodTable'ının adresini yazar</span></span>
4. Kalan alanı sıfırlar, constructor'ı çağırır</span></span>
5. Heap adresini stack'teki user değişkenine atar</span></span>
6. user.Name çağrısı: user adresi + 16 offset'inden string adresini okur</span></span></code></pre>
Bu mekanizmayı anladığınızda, performans problemlerinin çoğunu da anlamaya
başlarsınız. Her new</code> bir allocation'dır. GC'nin Gen 0 bölgesinde bir
tahsis bütçesi (allocation budget)</strong> vardır, yeni bir obje yaratmak,
bu bütçeyi tüketir. Bütçe sıfırlandığında GC tetiklenir ve kullanılmayan
nesneleri toplar. Yani her allocation, GC'nin bir sonraki toplama döngüsüne
sizi bir adım daha yaklaştırır. Her gereksiz allocation, önlenebilir bir
maliyettir.</p>
Bundan Sonrası</h2>
Stack ve heap'in ne olduğunu, CLR'ın obje yaratırken neler yaptığını,
MethodTable'ın rolünü ve string'in neden özel olduğunu gördük. Ama asıl
soru şu:</p>

"String işlerken heap allocation'dan nasıl kaçarız?"</p>
</blockquote>
Cevap: Span<T></code>, Memory<T></code>, stackalloc</code> ve IDisposable</code> pattern'i.
Yazının devamında bunları kod örnekleriyle ele alacağım. Ayrıca GC'nin
nesil (generation) mekanizmasına, finalizer'ların neden tehlikeli olduğuna
ve bellek sızıntılarını nasıl yakalayacağımıza da bakacağız.</p>
Kaynaklar</h2>

Microsoft Docs - Memory management and garbage collection</a></li>
Stephen Toub - All About Span: Exploring .NET Memory</a></li>
.NET Runtime - MethodTable source</a></li>
.NET Runtime - Object layout</a></li>
Eric Lippert - The Stack Is An Implementation Detail</a></li>
</ul>

Erdinç Yaşan

.NET'te Dependency Injection Nedir, Neden Kullanılır

Başlamadan önce</h2>
Bu yazıyı takip etmek için temel seviyede C# bilgisi yeterli: class, constructor, method ve interface kavramlarına aşina olmanız gerekiyor. Örnekleri kendiniz çalıştırmak isterseniz .NET 10 SDK kurulu olsun, veritabanı ya da başka bir kurulum gerekmiyor.</p>

Credential'ları repoda saklamak: SOPS + age

Cloudflare ve Gmail ile Kendi Domain'inden Ücretsiz E-posta

Git'te Yerel Ignore Kuralları: .git/info/exclude ve core.excludesFile

Kapanış</h2>
Özetle, .gitignore tek yer değil. Kişisel işler için `.git/info/exclude</code> ve core.excludesFile</code> var, ve bunlar repoya hiç dokunmuyor. Bir daha proje root'una geçici bir dosya bırakıp da "bunu nasıl gizlerim" diye düşündüğünde, çözüm bu.</p>`

PostgreSQL LIKE Performansı: CAST, Concat ve OR Karşılaştırması

.NET'te Bellek Yönetimi 1: Stack, Heap ve String'ler

`Kaynaklar</h2> Microsoft Docs - Memory management and garbage collection</a></li> Stephen Toub - All About Span: Exploring .NET Memory</a></li> .NET Runtime - MethodTable source</a></li> .NET Runtime - Object layout</a></li> Eric Lippert - The Stack Is An Implementation Detail</a></li> </ul>`

Erdinç Yaşan

.NET'te Dependency Injection Nedir, Neden Kullanılır

Başlamadan önce</h2> Bu yazıyı takip etmek için temel seviyede C# bilgisi yeterli: class, constructor, method ve interface kavramlarına aşina olmanız gerekiyor. Örnekleri kendiniz çalıştırmak isterseniz .NET 10 SDK kurulu olsun, veritabanı ya da başka bir kurulum gerekmiyor.</p>

Credential'ları repoda saklamak: SOPS + age

Cloudflare ve Gmail ile Kendi Domain'inden Ücretsiz E-posta

Git'te Yerel Ignore Kuralları: .git/info/exclude ve core.excludesFile

Kapanış</h2> Özetle, .gitignore tek yer değil. Kişisel işler için .git/info/exclude</code> ve core.excludesFile</code> var, ve bunlar repoya hiç dokunmuyor. Bir daha proje root'una geçici bir dosya bırakıp da "bunu nasıl gizlerim" diye düşündüğünde, çözüm bu.</p>

PostgreSQL LIKE Performansı: CAST, Concat ve OR Karşılaştırması

.NET'te Bellek Yönetimi 1: Stack, Heap ve String'ler

Başlamadan önce</h2>
Bu yazıyı takip etmek için temel seviyede C# bilgisi yeterli: class, constructor, method ve interface kavramlarına aşina olmanız gerekiyor. Örnekleri kendiniz çalıştırmak isterseniz .NET 10 SDK kurulu olsun, veritabanı ya da başka bir kurulum gerekmiyor.</p>

Kapanış</h2>
Özetle, .gitignore tek yer değil. Kişisel işler için `.git/info/exclude</code> ve core.excludesFile</code> var, ve bunlar repoya hiç dokunmuyor. Bir daha proje root'una geçici bir dosya bırakıp da "bunu nasıl gizlerim" diye düşündüğünde, çözüm bu.</p>`