DEV Community: Mustafa Çam

useRef

Mustafa Çam — Sat, 03 May 2025 20:40:52 +0000

Şimdi daha detaylı bir şekilde, bir benzetme ile açıklayalım.

`useRef` Ne İşe Yarar?

useRef, komponentin yeniden render edilmesini tetiklemeyen bir "değer tutucu" sağlar. Bu, bir değeri "saklamak" anlamına gelir, ama bu değer değiştiğinde UI yeniden render edilmez. Genellikle DOM referanslarına erişmek veya bir değişkeni render döngüsüne etki etmeden saklamak için kullanılır.

Benzetme:

Bir okul sınıfı düşün. Bu sınıfta öğretmen (React komponenti) var. Öğretmenin tahtada yazdığı her şey (UI) çok önemli, çünkü öğrenciler (kullanıcılar) bunu görerek öğreniyorlar.

useState öğretmenin tahta üzerine yazdığı yazıları ifade eder. Öğretmen her yazıyı değiştirdiğinde, öğrenciler buna bakacak ve öğrencilerin sınıfta başka işlere başlaması için tahta (UI) yeniden yazılacaktır.
useRef ise öğretmenin cebinde taşıdığı notlar gibi düşünülebilir. Bu notlar, öğrencilerin görmediği, ancak öğretmenin cebinde tuttuğu verilerdir. Eğer öğretmen bu notları değiştirirse, öğrenciler bunu görmez çünkü tahtada bir değişiklik olmayacaktır. Öğretmen sadece notları kullanarak dersini ilerletir ama bu, sınıftaki genel görünümü (UI) etkilemez.

`useRef` Kullanım Durumları:

1. DOM Erişimi:

useRef, genellikle DOM elemanlarına erişmek için kullanılır. Bir input elemanına odaklanmak, bir düğmeye tıklamak gibi işlemleri yapabilirsiniz. Bu tür işlemler, UI'ı değiştirmez; sadece arka planda gerçekleşir.

Örnek:

const inputRef = useRef(null);

const handleFocus = () => {
  inputRef.current.focus(); // Bu, input'a odaklanır ancak komponent yeniden render edilmez.
};

return (
  <div>
    <input ref={inputRef} />
    <button onClick={handleFocus}>Odaklan</button>
  </div>
);

2. Değerleri Saklamak (Render'ı Etkilemeden):

Bazen bir değeri saklamak istersiniz, ancak bu değerin değişmesi UI'ın yeniden render edilmesine yol açmamalıdır. Örneğin, bir zamanlayıcıyı takip etmek veya önceki bir değeri saklamak gibi.

Örnek:

const count = useRef(0);

const increment = () => {
  count.current += 1;
  console.log(count.current); // Bu, sayacın değerini tutar ama UI'ı değiştirmez.
};

return <button onClick={increment}>Arttır</button>;

Burada, count.current değişse de komponent yeniden render edilmez. Bu sayede, eski değerleri veya hesaplamaları tutabilirsiniz.

Temel Fark:

useState, UI'ı değiştirecek bir veri saklamak içindir ve bu verinin değişmesi her zaman render tetikler. useRef ise sadece veriyi tutmak için kullanılır ve bu verinin değişmesi UI'ın yeniden render edilmesine yol açmaz.

Özetle:

useState: UI'ı değiştiren değerler için.
useRef: Render'ı etkilemeden, sadece veri tutmak ya da DOM'a erişmek için.

langchain nedir ?

Mustafa Çam — Sat, 12 Apr 2025 18:30:56 +0000

LangChain, özellikle LLM'leri (Large Language Model / Büyük Dil Modelleri) daha güçlü ve işlevsel hale getirmek için geliştirilmiş bir Python (ve sonradan JavaScript) kütüphanesidir. LLM’leri veri kaynaklarıyla, araçlarla ve kullanıcı girdileriyle dinamik olarak birleştirerek daha gelişmiş uygulamalar oluşturmanı sağlar.

Basitçe söylemek gerekirse:

LangChain, ChatGPT gibi modellerin:

Gerçek verilerle konuşmasını,
Veritabanı sorgulaması yapmasını,
Web'den bilgi almasını,
Karmaşık iş akışlarını (pipeline) yönetmesini sağlayan bir altyapı sunar.

LangChain ile neler yapılabilir?

Veriye dayalı sohbet botları

Örneğin: "PDF dosyalarımla konuş", "Veritabanına bağlan ve bana rapor ver", "Web siteni analiz et".
Araç kullanan yapay zekâlar (Agent)

Mesela: Google'da arama yap, hesap makinesi kullan, takvim oluştur vb.
Chain (zincir) yapıları kurma

Çok adımlı LLM süreçleri:

Örneğin: Özet çıkar → Özetten soru üret → Cevapları analiz et
Bellekli sistemler (Memory)

ChatGPT gibi geçmiş mesajları hatırlayan sistemler geliştirebilirsin.

LangChain'in bazı önemli bileşenleri:

Bileşen	Açıklama
PromptTemplate	LLM'e ne sorulacağını şablonlaştırır
LLM	OpenAI, HuggingFace, Cohere gibi modellerle çalışır
Chains	Birden fazla adımı birbirine bağlar
Agents	Duruma göre hangi aracı kullanacağını seçen yapılar
Memory	Önceki sohbetleri hatırlama
Tools	Arama motoru, hesap makinesi gibi dış araçlar
Retrievers / Vector Stores	Belge arama için kullanılır (örneğin: FAISS, Pinecone)

Örnek bir senaryo:

“Bir PDF dökümanı yükle, içeriğini özetle, ardından kullanıcıdan gelen sorulara o özete göre cevap ver.”

Bu senaryo için LangChain:

PDF'den veri okur
Verileri vektör haline getirir (embedding)
ChatGPT’ye soruları iletirken bu verileri bağlar
Sonuçları kullanıcıya sunar

ef core select

Mustafa Çam — Tue, 08 Apr 2025 11:07:32 +0000

Entity Framework Core (EF Core) ile Select, veritabanındaki verileri sorgulamak ve yalnızca belirli alanları veya verileri almak için kullanılan bir LINQ (Language Integrated Query) metodudur. Select metodu, genellikle bir veri kümesinin her elemanını dönüştürmek veya sadece belirli özellikleri almak amacıyla kullanılır.

Temel Kullanım:

EF Core ile Select kullanarak sorgulama yaparken genellikle şu iki ana amaca yöneliriz:

Veri Seçimi: Sadece bazı alanları (sütunları) almak.
Veri Dönüştürme: Veriyi daha farklı bir türde almak (örneğin, bir DTO - Data Transfer Object).

1. Sadece Belirli Alanları Seçmek

Aşağıdaki örnekte, User tablosundaki yalnızca Name ve Email alanlarını seçiyoruz:

var users = dbContext.Users
    .Select(u => new { u.Name, u.Email })
    .ToList();

Bu sorgu, her bir User nesnesinin Name ve Email özelliklerini alır. Bu, veritabanı sorgusunda gereksiz verilerin çekilmesini engeller ve daha verimli bir sorgu yapılmasını sağlar.

2. Veriyi Dönüştürmek (DTO Kullanımı)

Veritabanı verilerini genellikle bir DTO sınıfına dönüştürmek de yaygın bir kullanım şeklidir. Aşağıda, User nesnelerini bir UserDto'ya dönüştürme örneği bulunmaktadır:

public class UserDto
{
    public string Name { get; set; }
    public string Email { get; set; }
}

var users = dbContext.Users
    .Select(u => new UserDto { Name = u.Name, Email = u.Email })
    .ToList();

Bu sorguda, User nesneleri UserDto nesnelerine dönüştürülüyor.

3. `Select` ile İlişkili Verileri Seçmek

EF Core'da ilişkili verileri de Select kullanarak sorgulamak mümkündür. Örneğin, bir Order tablosunda her bir siparişin Customer bilgilerini almak:

var orders = dbContext.Orders
    .Select(o => new 
    {
        o.OrderId,
        CustomerName = o.Customer.Name
    })
    .ToList();

Burada, her siparişin OrderId ve ona bağlı olan Customer'ın Name özelliği seçilmektedir.

Özet

Select metodu, EF Core'da veritabanından sadece gerekli verilerin alınmasını sağlamak ve performansı artırmak için yaygın olarak kullanılır. Aynı zamanda, verileri daha anlamlı hale getirmek için dönüştürme işlemleri (DTO, anonim tipler vb.) de yapılabilir.

Navigation Property neden var ? Amacımız ne ?

Mustafa Çam — Thu, 03 Apr 2025 12:53:39 +0000

AI ile oluşturuldu.

Çok güzel bir noktaya değindin! Entity Framework Core'da (EF Core) navigation property'lerin veritabanında doğrudan karşılığı olmaz. Şimdi neden böyle olduğunu detaylı açıklayayım.

1. Navigation Property Nedir?

Navigation property (User ve Words gibi) veritabanında doğrudan bir sütun olarak saklanmaz, sadece EF Core'un ilişkileri anlamasını ve kolayca sorgu yapabilmesini sağlar.

Yani şu Word entity'sindeki User property veritabanında yer almaz, ama EF Core onun sayesinde ilişkileri otomatik yönetir:

public class Word : BaseEntity<int>
{
    public string WordText { get; set; }

    public int UserId { get; set; } // FOREIGN KEY (Bu veritabanında vardır)

    public User User { get; set; } // NAVIGATION PROPERTY (Bu veritabanında YOKTUR)
}

UserId → Foreign Key olarak veritabanında bir sütun olarak bulunur.
User → Sadece EF Core'un ilişkileri takip etmesini sağlayan bir referanstır, veritabanında karşılığı yoktur.

2. Peki Navigation Property'nin Faydası Nedir?

Navigation property, veritabanı sorgularını yazmayı kolaylaştırır. Mesela aşağıdaki gibi bir User'ın kelimelerini çekmek için:

var userWords = _context.Users
    .Where(u => u.Id == userId)
    .Include(u => u.Words) // Navigation Property ile ilgili verileri getiriyoruz
    .FirstOrDefault();

EF Core, bu sorguyu arka planda JOIN'li bir SQL sorgusuna çevirir:

SELECT w.*
FROM Words w
JOIN Users u ON w.UserId = u.Id
WHERE u.Id = @userId;

Yani navigation property sayesinde LINQ ile yazılan sorgular otomatik olarak doğru JOIN işlemleri ile çevrilir.

3. Navigation Property Olmasaydı Ne Olurdu?

Eğer User navigation property’sini eklemezsen, ilişkiyi manuel olarak kurman gerekir. Örneğin:

var userWords = _context.Words
    .Where(w => w.UserId == userId)
    .ToList();

Burada doğrudan User objesi olmadan çalışırsın. Ama Include ile ilişkili verileri çekemezsin, manuel JOIN yapman gerekebilir ve kod okunurluğu azalır.

4. Özet

Navigation Property (User gibi) → EF Core içinde kullanılır, veritabanında karşılığı yoktur.
Foreign Key (UserId) → Veritabanında bir sütun olarak bulunur ve ilişkileri tanımlar.
EF Core, Navigation Property'leri kullanarak JOIN'leri otomatik yönetir.
Eğer navigation property olmasa, LINQ ile ilişkili veri çekmek daha zor olurdu.

Bu yüzden EF Core navigation property’leri sadece kod seviyesinde kullanır, ama ilişkiyi kurmak için Foreign Key’i (UserId) veritabanında tutar.

Anlaşılır oldu mu? Takıldığın bir nokta varsa açıklayabilirim! 🚀😎

Why is the foreign key in many table in one-to-many relationship

Mustafa Çam — Thu, 13 Mar 2025 06:41:01 +0000

Foreign Key (FK) "bire" tarafındaki tabloda bulunsaydı, şu problemlerle karşılaşırdık:

1. Çok Sayıda Kolon (Boş Alan) Olurdu

Her "bire" (Class) kaydı, kendisiyle ilişkili birden fazla "çok" (Student) kaydını referans almak zorunda kalırdı.

Örneğin, "Class" tablosuna öğrencileri eklemeye çalışsaydık:

Id	Name	Student1	Student2	Student3	Student4	...
1	10A	1	2	NULL	NULL	...
2	10B	3	NULL	NULL	NULL	...

Kaç öğrenci olacağını bilemeyeceğimiz için kolon sayısı sabit olamazdı.
Yeni bir öğrenci eklemek için Class tablosunun şemasını değiştirmemiz gerekirdi.
NULL değerler içeren gereksiz kolonlar oluşurdu.

2. Veritabanı Normalizasyonu Bozulurdu

Veritabanı tasarımında 1. normal form (1NF) gereği, bir alan (kolon) sadece tek bir değeri içermelidir.

FK, "bire" tarafında olursa, bir kolon birden fazla değeri tutamaz.
Bu nedenle çok tarafındaki satırları bireye bağlamak zorundayız.

3. Sorgular Karmaşıklaşır ve Performans Düşer

Normalde ClassId üzerinden öğrencilere ulaşmak hızlı ve kolay olur. Ancak:

"Bire" tarafına FK koyarsak, belirli bir öğrenciye hangi sınıfın ait olduğunu sorgulamak daha zor olur.
JOIN işlemleri daha karmaşık hale gelir ve performans kaybı yaşanır.

Sonuç:

Foreign Key (FK), "çok" tarafında olmalıdır!

📌 Çünkü:

✅ "Bire" tarafında FK olursa tasarım bozulur, gereksiz kolonlar oluşur, veri tekrarı olur ve performans düşer.

✅ "Çok" tarafında FK olursa her kayıt yalnızca 1 FK tutar, esnek olur ve sorgular hızlı çalışır.

Eğer tersini uygulayan bir veritabanı ile karşılaşırsan, yanlış bir tasarım olabilir ve düzeltilmesi gerekebilir. 😃

DIP'i İhlal Eden Durum

Mustafa Çam — Wed, 05 Mar 2025 14:33:09 +0000

Senaryo: E-posta Gönderme İşlemi

Bir EmailService sınıfımız olsun ve bu sınıf doğrudan bir somut sınıf olan SmtpClient'a bağımlı olsun. Bu durumda, SmtpClient'ı değiştirmek ya da farklı bir e-posta gönderme servisi eklemek istediğimizde, EmailService sınıfında değişiklik yapmak zorunda kalırız.

1. DIP'yi İhlal Eden Durum (Sıkı Bağlantı)

public class EmailService
{
    private SmtpClient _smtpClient;

    public EmailService()
    {
        _smtpClient = new SmtpClient();  // Direkt olarak SmtpClient'a bağlı.
    }

    public void SendEmail(string to, string subject, string body)
    {
        _smtpClient.Send(to, subject, body);
    }
}

public class SmtpClient
{
    public void Send(string to, string subject, string body)
    {
        Console.WriteLine($"E-posta gönderildi: {to}, {subject}, {body}");
    }
}

Sıkı Bağlantı Sorunu:

Şu anki yapımızda, EmailService sınıfı doğrudan SmtpClient sınıfına bağlıdır. Bu durumda, EmailService'in işlevselliğini değiştirmek istesek (örneğin, e-posta gönderme yöntemini değiştirmek veya başka bir e-posta servisi kullanmak gibi), EmailService sınıfında mutlaka değişiklik yapmamız gerekir.

Diyelim ki, yeni bir SendGridEmailClient eklemek istiyoruz ve EmailService'in SmtpClient'a olan bağımlılığını değiştirmemiz gerekiyor.

2. Değişiklik Yapma Zorunluluğu (Bağımlılıklar Sıkıdır)

Eğer EmailService doğrudan SmtpClient'a bağlıysa ve biz SendGrid kullanmaya karar verirsek, o zaman EmailService sınıfını değiştirmemiz gerekecek.

public class SendGridEmailClient
{
    public void Send(string to, string subject, string body)
    {
        Console.WriteLine($"E-posta gönderildi (SendGrid): {to}, {subject}, {body}");
    }
}

public class EmailService
{
    private SendGridEmailClient _sendGridEmailClient;

    public EmailService()
    {
        _sendGridEmailClient = new SendGridEmailClient();  // SendGrid'e geçiş yapıyoruz.
    }

    public void SendEmail(string to, string subject, string body)
    {
        _sendGridEmailClient.Send(to, subject, body);
    }
}

Değişiklikler:

EmailService'i değiştirmek zorunda kaldık çünkü SmtpClient'a olan bağımlılığı doğrudan yerleştirmiştik.
Ayrıca EmailService'i test etmek ya da başka bir servise entegre etmek için bu tür bağımlılıkları değiştirmeniz gerekecek.

3. DIP'yi Uygulayan Durum (Esnek ve Soyutlamalı)

Eğer DIP'yi uygularsak, EmailService sadece bir soyutlama olan IEmailClient'e bağlı olur ve somut sınıflar (SmtpClient, SendGridEmailClient) daha esnek bir şekilde değiştirilebilir.

public interface IEmailClient
{
    void Send(string to, string subject, string body);
}

public class SmtpEmailClient : IEmailClient
{
    public void Send(string to, string subject, string body)
    {
        Console.WriteLine($"E-posta gönderildi (SMTP): {to}, {subject}, {body}");
    }
}

public class SendGridEmailClient : IEmailClient
{
    public void Send(string to, string subject, string body)
    {
        Console.WriteLine($"E-posta gönderildi (SendGrid): {to}, {subject}, {body}");
    }
}

public class EmailService
{
    private readonly IEmailClient _emailClient;

    // Dependency Injection ile bağımlılık ekleniyor.
    public EmailService(IEmailClient emailClient)
    {
        _emailClient = emailClient;
    }

    public void SendEmail(string to, string subject, string body)
    {
        _emailClient.Send(to, subject, body);
    }
}

Esneklik Kazanma:

Şimdi, EmailService sınıfı sadece soyutlama olan IEmailClient'a bağlıdır.
EmailService'i değiştirmek zorunda kalmadan, farklı bir e-posta servis sağlayıcısı kullanabiliriz. Mesela SendGridEmailClient veya SmtpEmailClient gibi servisleri sadece IEmailClient'i implement eden sınıfları sağlayarak değiştirebiliriz.

public class Program
{
    public static void Main()
    {
        IEmailClient emailClient = new SendGridEmailClient();  // Ya da SmtpEmailClient
        var emailService = new EmailService(emailClient);

        emailService.SendEmail("test@example.com", "Konu", "E-posta içeriği");
    }
}

Sonuç:

DIP'yi ihlal ettiğimizde, EmailService sınıfını değiştirmek zorunda kalırız çünkü doğrudan somut sınıfa bağımlıdır. Yeni bir e-posta servisi eklediğimizde, bu servisin işlevini değiştirebilmek için EmailService'i de güncellememiz gerekir.
DIP'yi uyguladığımızda, soyutlamalar sayesinde EmailService sınıfını değiştirmeden yeni bir e-posta servisi ekleyebiliriz. Yüksek seviye modüller (iş mantığı) ve düşük seviye modüller (somut sınıflar) arasında bağımlılık yoktur, sadece soyutlama üzerinden iletişim vardır. Bu da daha esnek ve bakım kolaylığı sağlar.

Bu şekilde, bağımlılıkların sıkı olduğu durumlarda, değişiklik yaparken diğer sınıflarda da değişiklik yapmanız kaçınılmaz hale gelir. DIP, bu tür sorunları önleyerek yazılımın daha sürdürülebilir ve esnek olmasını sağlar.

Dependency Inversion Prensibi

Mustafa Çam — Wed, 05 Mar 2025 13:21:24 +0000

Dependency Inversion Principle (DIP), SOLID prensiplerinden biridir ve yazılımda bağımlılıkları yönetmek için çok önemli bir kavramdır. C# gibi nesne yönelimli dillerde, yazılımın esnekliğini ve bakımını kolaylaştırmak amacıyla kullanılır.

DIP, iki temel kuraldan oluşur:

Yüksek seviye modüller (veya sınıflar), düşük seviye modüllere bağımlı olmamalıdır. Her iki tür de abstraksiyonlara (soyutlamalara) bağımlı olmalıdır.

Yüksek seviye modüller, programın genel işlevselliğini sağlar (örneğin, bir iş mantığı sınıfı).
Düşük seviye modüller, daha spesifik işlevler sağlar (örneğin, veri erişim sınıfı).

Abstraksiyonlar (interface veya abstract class) somut sınıflardan (concrete classes) bağımsız olmalıdır.

Örnek ile Açıklama:

Bir örnek üzerinden açıklayalım. Diyelim ki, bir EmailService sınıfımız var ve bu sınıfın içinde bir SmtpClient'a bağımlılığı var. Eğer EmailService doğrudan SmtpClient sınıfına bağlıysa, bu durum DIP'yi ihlal eder çünkü EmailService yüksek seviye bir iş mantığı sınıfıyken, SmtpClient daha düşük seviye bir sınıftır.

DIP'yi uygularsak, EmailService'in SmtpClient'a olan bağımlılığını kaldırabiliriz. Bunun yerine, bir abstraction (soyutlama) olan IEmailClient adında bir arayüz (interface) oluştururuz ve EmailService sadece bu arayüze bağımlı olur. Bu şekilde, EmailService sınıfı daha esnek hale gelir ve farklı e-posta servisleri kullanılabilir.

Kod Örneği

DIP'yi ihlal eden kod:

public class EmailService
{
    private SmtpClient _smtpClient;

    public EmailService()
    {
        _smtpClient = new SmtpClient();  // Direkt olarak SmtpClient'a bağlı.
    }

    public void SendEmail(string to, string subject, string body)
    {
        _smtpClient.Send(to, subject, body);
    }
}

DIP'yi uygulayan kod:

public interface IEmailClient
{
    void Send(string to, string subject, string body);
}

public class SmtpEmailClient : IEmailClient
{
    public void Send(string to, string subject, string body)
    {
        // SmtpClient kullanılarak e-posta gönderimi yapılır.
    }
}

public class EmailService
{
    private readonly IEmailClient _emailClient;

    public EmailService(IEmailClient emailClient)
    {
        _emailClient = emailClient;  // Artık sadece soyutlamaya (IEmailClient) bağlı.
    }

    public void SendEmail(string to, string subject, string body)
    {
        _emailClient.Send(to, subject, body);
    }
}

Bu şekilde EmailService sınıfı IEmailClient arayüzüne bağlıdır ve artık SmtpClient gibi somut bir sınıfa doğrudan bağımlı değildir. Böylece:

EmailService sınıfı esnek hale gelir, çünkü farklı e-posta gönderme yöntemleri (örneğin, SendGridEmailClient) kolayca entegre edilebilir.
Bağımlılıkları yönetmek için Dependency Injection kullanılabilir.

Sonuç:
DIP, yazılımın sürdürülebilirliğini artırır, bağımlılıkları yönetmeyi kolaylaştırır ve test edilebilirliği artırır.

If you think debounce or onblur is not working in React, you can check it.

Mustafa Çam — Wed, 01 Jan 2025 16:49:56 +0000

Answer: If you have set up a structure to directly see the updated state in order to work with the value value in the input value, onchange, and then you have thought about the logic of debounce or onblur so that it does not render after the state change, and if you are wondering why you cannot enter a value into the input, then the value of the input value is the value of the input value. You can remove the value.

Example:

 <input
                  type="text"
                  name="example"
                  // value={example}  this is the comment line
                  onChange={handleOnchange}
                  className={`w-2/3 p-2`}
                />

this way onblur and debounce can work.

IEnumerable nedir ?

Mustafa Çam — Sat, 05 Oct 2024 21:04:11 +0000

IEnumerable, C# ve .NET Core'da koleksiyonlar üzerinde işlem yapmak için sıklıkla kullanılan bir arayüzdür (interface). Bu arayüz, bir veri kaynağının üzerinde yineleme (iteration) yapabilmeyi sağlar. IEnumerable, veri yapısına ya da koleksiyonun nasıl oluşturulduğuna bakılmaksızın, tek tek veri öğelerine erişme yeteneği sunar. Bu, temel olarak koleksiyonlar üzerinde dolaşmak ve verilerle işlem yapmak için kullanılan en yaygın arabirimlerden biridir.

`IEnumerable` Nedir?

IEnumerable, temel olarak bir veri koleksiyonunda ardışık veri öğelerine sadece ileriye doğru erişim sağlar.
Bu arayüz, veri koleksiyonlarını temsil eden sınıflarda kullanılan bir kontrattır. Yani, IEnumerable arayüzünü uygulayan her sınıf, foreach döngüsü gibi yapıların kullanılmasını sağlar.
Koleksiyon türüne bağlı olarak, IEnumerable koleksiyonun tüm verilerini bellekte tutmak zorunda değildir. Bu da özellikle lazy evaluation (ertelemeli değerlendirme) gibi tekniklerle performans avantajı sağlar.

Generic ve Non-generic Versiyonları

C#'ta IEnumerable iki temel versiyonla gelir:

IEnumerable (non-generic): Koleksiyonun elemanlarının türünü belirtmez.
IEnumerable<T> (generic): Koleksiyonda yer alan elemanların türünü belirtir ve tür güvenliğini sağlar.

`IEnumerable` ve `IEnumerator`

IEnumerable arayüzü bir yineleme başlatmak için kullanılır. Bu başlatma işini GetEnumerator() metodu aracılığıyla yapar.
IEnumerator, IEnumerable arayüzünden döndürülen yineleyicidir. Yani, bir koleksiyonun öğeleri arasında dolaşmak için IEnumerator kullanılır.
- IEnumerator şu metodları sağlar:
- MoveNext(): Bir sonraki öğeye geçer ve başarı durumunu döner.
- Current: Şu anda işaret edilen öğeyi döner.
- Reset(): Yineleyiciyi başa döndürür.

`IEnumerable` Kullanımına Örnekler

Non-generic IEnumerable

using System;
using System.Collections;

class Program
{
    static void Main()
    {
        ArrayList numbers = new ArrayList() { 1, 2, 3, 4, 5 };

        // IEnumerable interface'ini kullanarak üzerinde gezinme
        IEnumerable enumerable = numbers;

        IEnumerator enumerator = enumerable.GetEnumerator();

        while (enumerator.MoveNext())
        {
            Console.WriteLine(enumerator.Current);
        }
    }
}

Açıklama: Bu örnekte ArrayList gibi non-generic bir koleksiyon üzerinde IEnumerable kullanılarak veriler üzerinde geziniliyor. Burada, GetEnumerator() ile IEnumerator nesnesi elde edilip, MoveNext() ve Current ile sırayla öğeler işleniyor.

Generic `IEnumerable<T>`

using System;
using System.Collections.Generic;

class Program
{
    static void Main()
    {
        List<string> fruits = new List<string> { "Apple", "Banana", "Cherry" };

        // Generic IEnumerable kullanımı
        IEnumerable<string> fruitEnum = fruits;

        foreach (string fruit in fruitEnum)
        {
            Console.WriteLine(fruit);
        }
    }
}

Açıklama: Burada List<string> gibi generic bir koleksiyon üzerinde yineleme yapılıyor. IEnumerable<T> tür güvenliği sağlar ve tip dönüşümleri ile ilgili ekstra işlem yapılmasına gerek kalmaz.

`IEnumerable` ve `IEnumerator` İlişkisi

IEnumerable, her ne kadar kendi başına bir koleksiyon üzerinde gezmeyi sağlayan bir arayüz gibi görünse de aslında bu işi IEnumerator aracılığıyla yapar. IEnumerable, sadece bir GetEnumerator metodu sağlar, bu metod ise geri planda IEnumerator döner. Yani, IEnumerator, koleksiyonun öğelerine sırayla erişilmesini sağlayan asıl yapıdır.

Özetle, bu ilişki şu şekilde çalışır:

Bir IEnumerable koleksiyon üzerinde GetEnumerator çağrıldığında, o koleksiyonun bir yineleyicisi (IEnumerator) elde edilir.
IEnumerator, MoveNext() metoduyla bir sonraki öğeye geçer ve Current ile o öğeye erişilir.
İşlem bittikten sonra Reset() ile yineleyici başa döndürülebilir (ancak genellikle foreach kullanıldığında buna gerek kalmaz).

`IEnumerable` ve `IQueryable` Arasındaki Fark

IEnumerable: Veriyi bellekte işler ve döner. Yani, veriyi çeker ve döngü içerisinde işleme başlar. Tüm veriler bellekte olduğu için daha küçük veri kümeleriyle çalışmak için uygundur.
IQueryable: Sorguyu veri kaynağına gönderir ve veri kaynağının (örneğin bir veritabanı) işlemesini sağlar. Büyük veri kümeleriyle çalışırken daha performanslı olabilir çünkü sorgu veritabanında çalıştırılır.

`IEnumerable` ve `List<T>` Arasındaki Fark

IEnumerable<T>: Koleksiyonun sadece üzerinde gezinmenizi sağlar, veri üzerinde değişiklik yapamazsınız.
List<T>: Hem veri üzerinde değişiklik yapabilir hem de veriler arasında dolaşabilirsiniz (ekleme, silme, güncelleme gibi).

IEnumerable, veri koleksiyonlarını temsil eder; o koleksiyonun kendisi değildir. Bu nedenle, IEnumerable ile veri üzerinde değişiklik yapmak mümkün değildir. Örneğin, bir List<T> türü hem koleksiyonu temsil eder hem de veri üzerinde değişiklik yapmanıza olanak tanır.

`IEnumerable`'in Avantajları

Performans: IEnumerable, özellikle büyük veri kümeleriyle çalışırken lazy evaluation (ertelemeli değerlendirme) kullanarak bellek performansını artırır. Yani, tüm veri setini bellek içine alıp işlemek yerine sadece ihtiyaç duyulan veriler işlenir.
Kolaylık: IEnumerable, koleksiyonlar arasında basit bir iterasyon (yineleme) sağlar ve birden fazla veri türüyle çalışmak için uygundur.
Uyumluluk: Farklı veri kaynaklarıyla (diziler, listeler, veritabanları) çalışırken veri üzerinde kolayca dolaşmak mümkündür.

Dezavantajlar

Sınırlı Erişim: IEnumerable sadece ileriye doğru iterasyon sağlar, yani veriler üzerinde geriye dönük dolaşım yapılamaz.
Yalnızca Okuma: IEnumerable veriyi sadece okumaya yöneliktir, yani koleksiyon üzerinde değişiklik yapmanıza olanak tanımaz.

`IEnumerable` İle `yield` Anahtar Kelimesi

yield anahtar kelimesi, IEnumerable ile birlikte kullanıldığında bir koleksiyonun elemanlarını döndürmek için oldukça kullanışlıdır. Bu, veri işlemeyi daha verimli hale getiren "lazy evaluation" tekniğinin bir parçasıdır.

using System;
using System.Collections.Generic;

class Program
{
    static void Main()
    {
        foreach (int number in GetNumbers())
        {
            Console.WriteLine(number);
        }
    }

    static IEnumerable<int> GetNumbers()
    {
        yield return 1;
        yield return 2;
        yield return 3;
    }
}

Açıklama: yield, her çağrıldığında sıradaki öğeyi döndürür ve kaldığı yerden devam eder. Bu da hafıza tüketimini azaltır ve sadece ihtiyaç duyulan veriyi işleme alır.

Sonuç

IEnumerable, C# ve .NET Core'da koleksiyonlar üzerinde dolaşmak için temel bir yapı taşıdır. Esnekliği ve basitliği sayesinde veri kaynakları üzerinde işlem yapmayı kolaylaştırır. Yineleme mantığını IEnumerator ile sağlar ve veriyi bellek açısından daha verimli işleyebilir. Özellikle büyük veri kümeleriyle çalışırken yield ve IQueryable gibi diğer yapılarla birlikte kullanıldığında daha verimli sonuçlar elde edilebilir.

structural directives in Angular

Mustafa Çam — Sun, 22 Sep 2024 16:52:34 +0000

Angular'da *ngIf, *ngFor gibi yapılar, yapısal direktifler (structural directives) olarak adlandırılır. Bu direktifler, HTML'deki elementlerin yapısını değiştirmek veya kontrol etmek için kullanılır.

Yapısal Direktifler Nedir?

Yapısal direktifler, HTML DOM ağacında elementleri ekleyip kaldırmaya yarayan direktiflerdir.
Bu direktifler, bileşenlerin veya sayfaların görünümünü dinamik olarak değiştirmemize olanak tanır.
* işareti, bu direktiflerin yapısal olduğunu ifade eder. Bu işaret Angular tarafından kısa bir gösterim olarak kabul edilir ve aslında bu direktiflerin DOM elementini manipüle ettiğini belirtir.

En Yaygın Yapısal Direktifler:

*ngIf:
- Belirtilen koşul doğruysa (true) HTML elementini DOM'a ekler, aksi takdirde çıkarır.
- Örnek:
```
 <div *ngIf="isVisible">Bu metin sadece 'isVisible' true olduğunda görünür.</div>
```
*ngFor:
- Bir dizi veya koleksiyon üzerinde döngü yaparak HTML elementlerini tekrarlar.
- Örnek:
```
 <ul>
   <li *ngFor="let item of items">{{ item }}</li>
 </ul>
```

*ngSwitch:

Belirli bir duruma göre farklı bileşen veya elementleri görüntülemek için kullanılır.
Örnek:

 <div [ngSwitch]="day">
   <p *ngSwitchCase="'Monday'">Bugün Pazartesi</p>
   <p *ngSwitchCase="'Tuesday'">Bugün Salı</p>
   <p *ngSwitchDefault>Bugün Hafta Sonu</p>
 </div>

Direktif Türleri:

Yapısal Direktifler:
- HTML'deki elementlerin yapısını değiştirir (ekler veya çıkarır).
- Örnekler: *ngIf, *ngFor, *ngSwitch.
Öznitelik Direktifleri (Attribute Directives):
- Bir elementin görünümünü veya davranışını değiştirir, ancak elementin yapısını değiştirmez.
- Örnek: [ngClass], [ngStyle], ngModel.

Özet:

*ngIf ve *ngFor gibi özelliklere yapısal direktifler denir.
Yapısal direktifler, DOM üzerinde elementleri dinamik olarak ekleyip kaldırır.
Angular'da ayrıca öznitelik direktifleri de vardır ve bunlar elementin stilini veya davranışını değiştirir.

@Injectable() in Angular

Mustafa Çam — Sun, 22 Sep 2024 16:04:22 +0000

Evet, Angular 6 ve üzeri versiyonlarda, servislerin @Injectable() dekoratörüyle birlikte providedIn özelliği kullanılarak providers kısmına yazmadan da servisleri kullanabiliyorsunuz. Bu, Angular'ın dependency injection (bağımlılık enjeksiyonu) sisteminin bir parçasıdır ve servislerin uygulamanın genelinde ya da belirli modüllerde nasıl sağlanacağını kontrol eder.

`@Injectable({ providedIn: 'root' })` Ne Anlama Gelir?

Angular'da servisler, modüller ve bileşenler arasındaki ortak işlevleri sağlamak için kullanılır. Bir servisin nerede kullanılacağını belirtmek için iki temel yol vardır:

@Injectable() ile providedIn kullanmak: Servisin hangi modülde veya kapsamda sağlanacağını belirtir.
Modülün providers kısmına servis eklemek: Bu eski yöntemdir ve genellikle hala geçerlidir, ancak Angular 6 ile birlikte providedIn özelliği daha yaygın hale geldi.

Örnek: `providedIn: 'root'`

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root'  // Bu servis uygulamanın kök seviyesinde (global) sağlanır.
})
export class UserService {
  constructor() { }
}

providedIn: 'root': Bu özellik, Angular'a bu servisi uygulamanın genelinde sağlayacağını (singleton olarak) bildirir. Yani servis app.module.ts dosyasının providers kısmına eklenmesine gerek kalmaz.
Bu sayede servis, uygulamanın herhangi bir bileşeninde veya başka bir serviste doğrudan constructor ile kullanılabilir.

Neden `providers` Alanına Eklemeye Gerek Yok?

Angular'ın yeni sürümleriyle birlikte providedIn ile servislerin uygulamanın global scope'unda veya belirli modüllerde sağlanmasını sağlıyoruz. Bu şu avantajları getirir:

Daha Basit ve Temiz Kod: providers kısmına eklemeye gerek kalmaz.
Ağaç Sallama (Tree Shaking): Eğer servis hiçbir yerde kullanılmazsa, Angular uygulamanın derlemesi sırasında bu servisi koddan kaldırabilir (daha küçük bundle boyutu).
Global veya Modül Bazında Sağlanabilirlik: providedIn ile servisin globalde mi yoksa sadece belirli bir modülde mi sağlanacağını belirleyebilirsiniz.

Eğer Modül Bazında Sağlamak İsterseniz:

@Injectable({
  providedIn: SomeModule  // Bu servis sadece SomeModule içinde kullanılabilir.
})
export class SomeService {
  constructor() { }
}

Bu durumda servis yalnızca SomeModule yüklendiğinde aktif hale gelir ve kullanılabilir.

Eski Yöntem: `providers` Kısmına Servis Ekleme

Eski Angular sürümlerinde veya bazı durumlarda, servisleri modülün providers kısmına ekleyerek kullanılabilir hale getirirdik. Örneğin:

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { UserService } from './user.service';

@NgModule({
  imports: [CommonModule],
  providers: [UserService]  // Servis burada tanımlanır
})
export class UserModule { }

Ancak artık bu yönteme çoğunlukla gerek kalmamıştır, çünkü providedIn daha modern ve kullanışlı bir yaklaşımdır.

Özet:

@Injectable({ providedIn: 'root' }) ile servisler global olarak sağlanır, bu nedenle providers kısmına eklemeye gerek kalmaz.
Eğer servisi belirli bir modülde sağlamak isterseniz, providedIn parametresiyle modülü belirtebilirsiniz.
Eski yöntem olan providers kısmına servis eklemek hala geçerli bir yöntemdir, ancak genellikle providedIn yaklaşımı tercih edilir çünkü daha basit ve verimlidir.

Lazy loading vs Eager loading

Mustafa Çam — Wed, 18 Sep 2024 13:38:01 +0000

Eager Loading ve Lazy Loading iki farklı veri yükleme stratejisidir ve Entity Framework Core'da ilişkili verilerle çalışma şeklini etkiler. İşte bu iki yöntem arasındaki temel farklar:

1. Eager Loading (Önceden Yükleme)

Eager Loading, ilişkili verilerin sorgu yapıldığında hemen yüklenmesini sağlar. Bu yöntem, ilişkili verilerin aynı anda ve tek bir sorgu içinde getirilmesini sağlar. Genellikle Include metodunu kullanarak ilişkili verileri yükleyebilirsiniz.

Özellikleri:

Veri Çekme: İlişkili veriler, ana verilerle birlikte tek bir sorguda getirilir.
Performans: Birden fazla sorgu yapmak yerine, ilişkili verilerle birlikte tek bir sorgu gönderildiği için performans avantajı sağlar. Ancak, çok büyük veri setlerinde bu sorguların performansı etkilenebilir.
Kullanım: İlişkili verileri her zaman kullanmanız gerekiyorsa uygun bir yöntemdir.

Örnek:

Bir öğrenci ve onun derslerini aynı anda getirmek istiyorsanız:

var students = context.Students
                      .Include(s => s.Courses) // Öğrencinin derslerini de getirir
                      .ToList();

2. Lazy Loading (Tembel Yükleme)

Lazy Loading, ilişkili verilerin yalnızca ihtiyaç duyulduğunda yüklenmesini sağlar. İlk sorguda yalnızca ana veri getirilir ve ilişkili veriler, erişilmeye çalışıldığında dinamik olarak veritabanından yüklenir. Lazy Loading, genellikle virtual keyword ile ilişkilendirilmiş navigation property'leri kullanır.

Özellikleri:

Veri Çekme: İlişkili veriler yalnızca erişildiğinde yüklenir. İlk başta yalnızca ana veriler getirilir.
Performans: Gereksiz veri yüklemesi önlenir, ancak ilişkili verilere erişildiğinde ek sorgular yapılır. Bu, büyük veri setlerinde fazla sorgu yapılmasına neden olabilir.
Kullanım: İlişkili verilere genellikle ihtiyaç duyulmuyorsa veya sadece bazı durumlarda erişilmesi gerekiyorsa uygun bir yöntemdir.

Örnek:

Bir öğrenci verisini aldıktan sonra, derslere yalnızca ihtiyacınız olduğunda erişmek istiyorsanız:

var student = context.Students.Find(1); // Sadece öğrenci verisi getirilir

// İlişkili dersler, öğrenciye erişildikten sonra gerektiğinde yüklenir
foreach (var course in student.Courses)
{
    Console.WriteLine(course.CourseName); // Bu noktada Courses verisi getirilir
}

Karşılaştırma

Sorgu Sayısı:
- Eager Loading: Tek bir sorgu ile ana ve ilişkili verileri getirebilir. Performans genellikle daha iyi olabilir, ancak büyük veri setlerinde veri aşırı yüklenmesine neden olabilir.
- Lazy Loading: İlişkili veriler için ek sorgular yapar. İlişkilere erişildiğinde daha fazla sorgu yapıldığı için performans problemleri yaşanabilir.
Veri Miktarı:
- Eager Loading: Daha fazla veri getirir çünkü ilişkili veriler de yüklenir. Bu, gereksiz veri getirilmesine neden olabilir.
- Lazy Loading: Sadece erişildiğinde ilişkili veriler yüklenir, böylece gereksiz veriler getirilmez.
Performans:
- Eager Loading: Genellikle daha performanslı olabilir çünkü sadece bir sorgu yaparak tüm gerekli veriler getirilir.
- Lazy Loading: Ek sorgular gerektirdiği için bazı durumlarda performans sorunlarına yol açabilir.

Özet

Eager Loading: İlişkili verileri, ana verilerle birlikte önceden yükler. Tek bir sorguda tüm veriler getirilir, bu da performans avantajı sağlar ancak büyük veri setlerinde veritabanı aşırı yüklenmesine neden olabilir.
Lazy Loading: İlişkili verileri yalnızca ihtiyaç duyulduğunda yükler. İlk sorguda sadece ana veriler getirilir, ilişkili verilere erişildiğinde ek sorgular yapılır. Performansı artırabilir, ancak çok sayıda sorgu yapabilir.

Kullanım senaryonuza bağlı olarak bu yöntemlerden birini seçebilirsiniz. Örneğin, ilişkili verilere her zaman ihtiyacınız varsa eager loading, yalnızca bazı durumlarda ihtiyaç duyuyorsanız lazy loading tercih edilebilir.

DEV Community: Mustafa Çam

useRef

useRef Ne İşe Yarar?

Benzetme:

useRef Kullanım Durumları:

1. DOM Erişimi:

2. Değerleri Saklamak (Render'ı Etkilemeden):

Temel Fark:

langchain nedir ?

Basitçe söylemek gerekirse:

LangChain ile neler yapılabilir?

LangChain'in bazı önemli bileşenleri:

Örnek bir senaryo:

ef core select

Temel Kullanım:

1. Sadece Belirli Alanları Seçmek

2. Veriyi Dönüştürmek (DTO Kullanımı)

3. Select ile İlişkili Verileri Seçmek

Özet

Navigation Property neden var ? Amacımız ne ?

1. Navigation Property Nedir?

2. Peki Navigation Property'nin Faydası Nedir?

3. Navigation Property Olmasaydı Ne Olurdu?

4. Özet

Why is the foreign key in many table in one-to-many relationship

1. Çok Sayıda Kolon (Boş Alan) Olurdu

2. Veritabanı Normalizasyonu Bozulurdu

3. Sorgular Karmaşıklaşır ve Performans Düşer

Sonuç:

DIP'i İhlal Eden Durum

Senaryo: E-posta Gönderme İşlemi

1. DIP'yi İhlal Eden Durum (Sıkı Bağlantı)

Sıkı Bağlantı Sorunu:

2. Değişiklik Yapma Zorunluluğu (Bağımlılıklar Sıkıdır)

3. DIP'yi Uygulayan Durum (Esnek ve Soyutlamalı)

Esneklik Kazanma:

Sonuç:

Dependency Inversion Prensibi

Kod Örneği

If you think debounce or onblur is not working in React, you can check it.

IEnumerable nedir ?

IEnumerable Nedir?

Generic ve Non-generic Versiyonları

IEnumerable ve IEnumerator

IEnumerable Kullanımına Örnekler

Non-generic IEnumerable

Generic IEnumerable<T>

IEnumerable ve IEnumerator İlişkisi

IEnumerable ve IQueryable Arasındaki Fark

IEnumerable ve List<T> Arasındaki Fark

IEnumerable'in Avantajları

Dezavantajlar

IEnumerable İle yield Anahtar Kelimesi

Sonuç

structural directives in Angular

Yapısal Direktifler Nedir?

En Yaygın Yapısal Direktifler:

Direktif Türleri:

Özet:

@Injectable() in Angular

@Injectable({ providedIn: 'root' }) Ne Anlama Gelir?

Örnek: providedIn: 'root'

Neden providers Alanına Eklemeye Gerek Yok?

Eğer Modül Bazında Sağlamak İsterseniz:

Eski Yöntem: providers Kısmına Servis Ekleme

Özet:

Lazy loading vs Eager loading

1. Eager Loading (Önceden Yükleme)

Özellikleri:

Örnek:

2. Lazy Loading (Tembel Yükleme)

Özellikleri:

Örnek:

Karşılaştırma

Özet

`useRef` Ne İşe Yarar?

`useRef` Kullanım Durumları:

3. `Select` ile İlişkili Verileri Seçmek

`IEnumerable` Nedir?

`IEnumerable` ve `IEnumerator`

`IEnumerable` Kullanımına Örnekler

Generic `IEnumerable<T>`

`IEnumerable` ve `IEnumerator` İlişkisi

`IEnumerable` ve `IQueryable` Arasındaki Fark

`IEnumerable` ve `List<T>` Arasındaki Fark

`IEnumerable`'in Avantajları

`IEnumerable` İle `yield` Anahtar Kelimesi

`@Injectable({ providedIn: 'root' })` Ne Anlama Gelir?

Örnek: `providedIn: 'root'`

Neden `providers` Alanına Eklemeye Gerek Yok?

Eski Yöntem: `providers` Kısmına Servis Ekleme