PHP’de Temiz ve Sürücü Bilinçli ORM Mimarisi: Derinlemesine Bir Bakış

Veritabanı işlemleri, modern web uygulamalarının karmaşık ve hata yapmaya açık bir parçası olabilir. Peki, uygulamanızın farklı veritabanı türleriyle sorunsuz bir şekilde konuşmasını sağlarken, aynı zamanda kodu daha okunabilir ve sürdürülebilir hale getirecek sihirli bir yöntem var mı? Bu makalede, PHP’de “Temiz” ve “Sürücü Bilinçli” bir ORM (Object-Relational Mapping) mimarisinin nasıl inşa edileceğini, gerçek dünya senaryolarıyla adım adım açıklayacağız.

Her PHP geliştiricisi, kariyerinin bir noktasında doğrudan SQL sorgularıyla boğuşmuştur. mysqli_query veya PDO kullanarak yazılan her SQL cümlesi, genellikle tekrar eden kalıplar içerir: bağlantı kurma, sorguyu hazırlama, parametreleri bağlama, çalıştırma, sonuçları çekme ve hata yönetimi. Bu süreç, küçük projeler için idare edilebilir olsa da, büyük ve karmaşık uygulamalarda hızla bir kabusa dönüşebilir. Veritabanı şeması değiştiğinde, ilgili her SQL sorgusunu manuel olarak güncellemek zorunda kalmak, zaman alıcı ve hataya açık bir iştir. Ayrıca, SQL enjeksiyonu gibi güvenlik açıklarıyla mücadele etmek de ayrı bir yüktür.

İşler daha da karmaşıklaşır: ya projeniz başlangıçta MySQL kullanırken, bir noktada PostgreSQL veya SQL Server’a geçme ihtiyacı duyarsa? Doğrudan SQL sorguları yazıyorsanız, bu geçiş neredeyse tüm veri erişim katmanınızı yeniden yazmak anlamına gelebilir. Her veritabanının kendi SQL lehçesi ve özgüllükleri vardır; örneğin, LIMIT/OFFSET sentaksı farklılık gösterebilir veya bazı veri tipleri farklı şekilde ele alınabilir. İşte tam bu noktada, ORM mimarileri devreye girer. ORM’ler, veritabanı işlemlerini nesne odaklı bir yaklaşımla soyutlayarak bu sorunlara zarif çözümler sunar. Ancak her ORM aynı değildir; “temiz” ve “sürücü bilinçli” bir yaklaşım benimsemek, bu araçların gerçek potansiyelini ortaya çıkarır. Temiz bir ORM, uygulamanızın diğer katmanlarından veri erişim mantığını ayırırken, sürücü bilinçli bir yapı, veritabanı sağlayıcısından bağımsızlık sağlayarak esnekliği en üst düzeye çıkarır. Bu sayede, geliştiriciler veritabanının altındaki karmaşık SQL detaylarına takılmak yerine, uygulamanın iş mantığına odaklanabilirler. Bu yaklaşım, sadece kodu basitleştirmekle kalmaz, aynı zamanda test edilebilirliği, bakımı ve gelecekteki ölçeklenebilirliği de önemli ölçüde iyileştirir.

Temel Kavramlar: ORM Nedir ve Neden İhtiyacımız Var?

ORM, yani Object-Relational Mapping (Nesne-İlişkisel Eşleştirme), ilişkisel veritabanları ile nesne tabanlı programlama dilleri arasındaki uyumsuzlukları çözmek için kullanılan bir programlama tekniğidir. Kısaca, veritabanındaki tabloları ve satırları, PHP’deki nesnelere (sınıflara ve bu sınıfların örneklerine) dönüştürmeyi sağlar. Bu sayede, geliştiriciler veritabanı tablolarıyla doğrudan SQL sorguları yazmak yerine, PHP nesneleriyle etkileşime girerek veri işlemleri yapabilirler. Bir User nesnesini düşünün; bu nesne, veritabanındaki users tablosundaki bir satırı temsil edebilir. $user->save() veya User::find(1) gibi yöntemlerle veritabanıyla etkileşime geçmek, SQL bilmekten çok daha sezgiseldir.

Peki, bir ORM’e neden ihtiyacımız var? Birincisi, üretkenliği artırır. ORM’ler, geliştiricilerin tekrar eden SQL yazma ve sonuç kümesi işleme gibi sıkıcı görevlerden kurtulmasını sağlar. İkincisi, bakımı kolaylaştırır. Veritabanı şeması değiştiğinde, ORM genellikle bu değişiklikleri otomatik olarak yönetir veya en azından değişikliklerin etkisini minimuma indirir. Üçüncüsü, SQL enjeksiyonu gibi güvenlik açıklarını önlemeye yardımcı olur. Parametre bağlama gibi güvenli uygulamaları varsayılan olarak sunar. Dördüncüsü, kodun okunabilirliğini ve anlaşılırlığını artırır. Nesne tabanlı bir arayüz, iş mantığını daha net bir şekilde ifade etmeyi sağlar. Son olarak, test edilebilirliği iyileştirir. Veritabanı işlemlerini soyutladığı için, birim testlerinde sahte veritabanı bağlantıları veya in-memory veritabanları kullanmak çok daha kolaydır.

Ancak, her ORM mükemmel değildir. Performans overhead’i, öğrenme eğrisi ve “leaky abstraction” riski (yani ORM’in altındaki veritabanı detaylarının sızması) gibi potansiyel dezavantajları da vardır. Bu dezavantajları en aza indirmek için “sürücü bilinçli” bir yaklaşım benimsemek kritiktir. “Sürücü Bilinçli” (Driver-Aware) ne anlama geliyor? Bu, ORM’in farklı veritabanı sistemlerinin (MySQL, PostgreSQL, SQL Server vb.) kendine özgü özelliklerini ve SQL lehçelerini anlayıp yönetebilmesi demektir. Örneğin, bir sorgu oluşturucu, MySQL için LIMIT ve OFFSET kullanırken, SQL Server için TOP veya ROW_NUMBER() OVER (...) gibi farklı sentaksları otomatik olarak uygulayabilmelidir. Bu, veritabanı sağlayıcısından bağımsızlık sağlayarak uygulamanızın esnekliğini ve geleceğe dönüklüğünü maksimize eder. Uygulamanızın temel veri erişim katmanı, kullandığınız veritabanının detaylarından haberdar olmalı ancak iş mantığı katmanı bu detaylardan tamamen soyutlanmış kalmalıdır. Bu ayrım, karmaşık projelerde esnekliği artırır, böylece geliştiriciler sistemin veri depolama katmanında yapılan değişiklikler hakkında endişelenmek zorunda kalmazlar.

Temiz Bir ORM Mimarisi Nasıl Tasarlanır? Katmanlara Ayrılmış Bir Yaklaşım

Temiz ve sürücü bilinçli bir ORM mimarisi oluşturmanın temelinde, sorumlulukların net bir şekilde ayrıştırılması yatar. Bu, genellikle birkaç ana katmana bölünerek başarılır:

1. Veritabanı Soyutlama Katmanı (Driver Layer): Doğrudan veritabanıyla etkileşim kuran en alt katmandır. PDO gibi bir PHP uzantısını kullanarak farklı veritabanlarına bağlanma ve temel sorguları çalıştırma yeteneği sağlar.
2. Sorgu Oluşturucu (Query Builder): Veritabanı sorgularını nesne tabanlı bir arayüzle oluşturmayı sağlayan katmandır. SQL sentaksının karmaşıklığını gizler ve sürücü bilinçli özellikleri burada devreye girer.
3. Veri Eşleme Katmanı (Data Mapper): Veritabanı satırlarını PHP nesnelerine ve PHP nesnelerini veritabanı satırlarına dönüştürmekten sorumludur.
4. Varlık Katmanı (Entity Layer): Uygulamanızdaki iş nesnelerini (varlıkları) temsil eden katmandır. Veritabanı bağımlılıklarından arındırılmış saf PHP nesneleridir.
5. Depo Katmanı (Repository Layer): Varlıklar için koleksiyon benzeri bir arayüz sağlar. Veri erişim mantığını iş mantığından ayırır ve Data Mapper’ı kullanır.

Veritabanı Soyutlama Katmanı (Driver Layer) Ne İşe Yarar?

Bu katman, ORM’imizin kalbidir ve farklı veritabanı sistemleriyle uyumluluğun temelini oluşturur. Amacımız, uygulamanın geri kalanının hangi veritabanını kullandığını bilmek zorunda kalmadan, standart bir arayüz üzerinden veritabanı işlemleri yapabilmesini sağlamaktır. PHP’de genellikle PDO (PHP Data Objects) bu soyutlamanın temelini oluşturur. Ancak PDO’nun kendisi de bir soyutlama olmasına rağmen, bazı veritabanlarına özgü farklılıklar (örneğin, sorgu sentaksı, hata kodları) hala mevcuttur. Bizim “Driver Layer”ımız, bu PDO farklılıklarını da soyutlayarak tam bir veritabanı bağımsızlığı sunar.

Öncelikle, tüm sürücülerin uygulayacağı bir arayüz tanımlarız:

interface DatabaseDriverInterface
{
    public function connect(array $config): void;
    public function disconnect(): void;
    public function query(string $sql, array $params = []): array;
    public function execute(string $sql, array $params = []): int;
    public function lastInsertId(): ?string;
    public function beginTransaction(): bool;
    public function commit(): bool;
    public function rollBack(): bool;
}

Şimdi, bu arayüzü uygulayan belirli sürücüler (örneğin, MySQL için) oluşturabiliriz:

class MySqlDriver implements DatabaseDriverInterface
{
    private ?\PDO $pdo = null;

    public function connect(array $config): void
    {
        $dsn = "mysql:host={$config['host']};dbname={$config['dbname']};charset={$config['charset']}";
        $this->pdo = new \PDO($dsn, $config['user'], $config['pass'], $config['options'] ?? []);
        $this->pdo->setAttribute(\PDO::ATTR_ERRMODE, \PDO::ERRMODE_EXCEPTION);
        $this->pdo->setAttribute(\PDO::ATTR_DEFAULT_FETCH_MODE, \PDO::FETCH_ASSOC);
    }

    public function disconnect(): void
    {
        $this->pdo = null;
    }

    public function query(string $sql, array $params = []): array
    {
        $stmt = $this->pdo->prepare($sql);
        $stmt->execute($params);
        return $stmt->fetchAll();
    }

    public function execute(string $sql, array $params = []): int
    {
        $stmt = $this->pdo->prepare($sql);
        $stmt->execute($params);
        return $stmt->rowCount();
    }

    public function lastInsertId(): ?string
    {
        return $this->pdo->lastInsertId();
    }

    public function beginTransaction(): bool
    {
        return $this->pdo->beginTransaction();
    }

    public function commit(): bool
    {
        return $this->pdo->commit();
    }

    public function rollBack(): bool
    {
        return $this->pdo->rollBack();
    }
}

Benzer şekilde, bir PostgreSqlDriver veya SqliteDriver da aynı DatabaseDriverInterface'i uygulayarak farklı veritabanları için özel bağlantı ve sorgu mantığı sağlayabilir. Bu yapı, uygulamanızın temel veritabanı operasyonlarını tamamen soyutlar ve alt katmanda herhangi bir veritabanı değişiminde, yalnızca ilgili sürücünün güncellenmesi veya yenisinin eklenmesi yeterli olur.

Veri Eşleme Katmanı (Data Mapper) Neden Gereklidir?

Veri Eşleme (Data Mapper) deseni, uygulamanızın veritabanı ile etkileşimini, iş nesnelerinizden (varlıklarınızdan) tamamen ayırır. Bu, "persistence ignorance" (kalıcılık bilgisizliği) ilkesini destekler; yani, varlık nesneleriniz veritabanına nasıl kaydedildikleri veya oradan nasıl yüklendikleri hakkında hiçbir bilgiye sahip değildir. Bu ayrım, bağımsızlığı artırır ve hem iş mantığının hem de veri erişim mantığının ayrı ayrı geliştirilmesine ve test edilmesine olanak tanır. Data Mapper, bir yandan veritabanından çekilen satırları PHP nesnelerine dönüştürürken, diğer yandan PHP nesnelerinin özelliklerini veritabanı sütunlarına eşleyerek kayıt veya güncelleme işlemlerini gerçekleştirir.

Her varlık (entity) için bir Data Mapper olacaktır. Örneğin, bir User varlığı için UserDataMapper şöyle görünebilir:

// Varlık (Entity) Tanımı
class User
{
    private ?int $id;
    private string $username;
    private string $email;
    private \DateTimeImmutable $createdAt;

    public function __construct(?int $id, string $username, string $email, \DateTimeImmutable $createdAt)
    {
        $this->id = $id;
        $this->username = $username;
        $this->email = $email;
        $this->createdAt = $createdAt;
    }

    // Getter ve Setter metotları
    public function getId(): ?int { return $this->id; }
    public function setId(int $id): void { $this->id = $id; } // Sadece yeni kayıtlar için
    public function getUsername(): string { return $this->username; }
    public function setUsername(string $username): void { $this->username = $username; }
    public function getEmail(): string { return $this->email; }
    public function setEmail(string $email): void { $this->email = $email; }
    public function getCreatedAt(): \DateTimeImmutable { return $this->createdAt; }
}

// Data Mapper Arayüzü
interface DataMapperInterface
{
    public function mapRowToObject(array $row): object;
    public function mapObjectToRow(object $object): array;
}

// User Data Mapper Uygulaması
class UserDataMapper implements DataMapperInterface
{
    public function mapRowToObject(array $row): User
    {
        // Veritabanı satırından User nesnesine eşleme
        return new User(
            $row['id'],
            $row['username'],
            $row['email'],
            new \DateTimeImmutable($row['created_at'])
        );
    }

    public function mapObjectToRow(object $user): array
    {
        if (!$user instanceof User) {
            throw new \InvalidArgumentException("Beklenen User nesnesi değil.");
        }
        // User nesnesinden veritabanı satırına eşleme
        return [
            'username' => $user->getUsername(),
            'email' => $user->getEmail(),
            'created_at' => $user->getCreatedAt()->format('Y-m-d H:i:s')
        ];
    }
}

Bu yapı sayesinde, User sınıfı veritabanı detaylarından tamamen habersiz kalırken, UserDataMapper sadece bu iki dünya arasındaki köprüyü kurma sorumluluğunu üstlenir. Bu, daha temiz, daha esnek ve daha test edilebilir bir mimariye yol açar. Örneğin, bir gün created_at sütununun adını creation_date olarak değiştirmek isterseniz, yalnızca UserDataMapper sınıfını güncellemeniz yeterli olur, User varlığında hiçbir değişiklik yapmanıza gerek kalmaz.

Sürücü Bilinçli ORM Uygulaması: Adım Adım Entegrasyon

Sürücü bilinçli bir ORM'in temel gücü, kullanılan veritabanı sürücüsüne göre farklı SQL sentakslarını ve özelliklerini otomatik olarak yönetebilmesidir. Bu, uygulamanın farklı veritabanı sistemleri arasında kolayca geçiş yapabilmesini sağlar. Bu bölümde, bu yeteneği nasıl entegre edeceğimizi ve ana bileşenlerini inceleyeceğiz.

Bir Sorgu Oluşturucu (Query Builder) Nasıl Geliştirilir?

Sorgu Oluşturucu (Query Builder), karmaşık SQL sorgularını nesne tabanlı, akıcı (fluent) bir arayüz kullanarak oluşturmamızı sağlayan merkezi bir bileşendir. Doğrudan SQL yazmaktan kaçınarak, hem kod okunabilirliğini artırır hem de SQL enjeksiyonu gibi güvenlik açıklarını azaltır. En önemlisi, sürücü bilinçli mimaride Query Builder, kullanılan DatabaseDriverInterface uygulamasına göre farklı veritabanı lehçelerini otomatik olarak dönüştürebilmelidir.

Basit bir QueryBuilder sınıfı şöyle görünebilir:

interface QueryBuilderInterface
{
    public function select(array $columns = ['*']): self;
    public function from(string $table): self;
    public function where(string $column, string $operator, mixed $value): self;
    public function limit(int $limit): self;
    public function offset(int $offset): self;
    public function build(): array; // ['sql' => ..., 'params' => ...]
    public function getDriver(): DatabaseDriverInterface;
}

class GenericQueryBuilder implements QueryBuilderInterface
{
    protected DatabaseDriverInterface $driver;
    protected array $parts = [];
    protected array $params = [];
    protected string $table = '';

    public function __construct(DatabaseDriverInterface $driver)
    {
        $this->driver = $driver;
    }

    public function getDriver(): DatabaseDriverInterface
    {
        return $this->driver;
    }

    public function select(array $columns = ['*']): self
    {
        $this->parts['select'] = 'SELECT ' . implode(', ', $columns);
        return $this;
    }

    public function from(string $table): self
    {
        $this->table = $table;
        $this->parts['from'] = 'FROM ' . $table;
        return $this;
    }

    public function where(string $column, string $operator, mixed $value): self
    {
        $paramName = ':where_' . count($this->params);
        $this->parts['where'][] = "{$column} {$operator} {$paramName}";
        $this->params[$paramName] = $value;
        return $this;
    }

    public function limit(int $limit): self
    {
        $this->parts['limit'] = $limit;
        return $this;
    }

    public function offset(int $offset): self
    {
        $this->parts['offset'] = $offset;
        return $this;
    }

    public function build(): array
    {
        $sql = [];
        if (isset($this->parts['select'])) {
            $sql[] = $this->parts['select'];
        }
        if (isset($this->parts['from'])) {
            $sql[] = $this->parts['from'];
        }
        if (!empty($this->parts['where'])) {
            $sql[] = 'WHERE ' . implode(' AND ', $this->parts['where']);
        }

        // Sürücü bilinçli limit/offset uygulaması
        if (isset($this->parts['limit']) || isset($this->parts['offset'])) {
            // Burası veritabanı sürücüsüne göre değişebilir.
            // Örneğin, MySQL için "LIMIT X OFFSET Y"
            // PostgreSQL için "LIMIT X OFFSET Y"
            // SQL Server için farklı bir yaklaşıma ihtiyaç duyulabilir (TOP veya ROW_NUMBER)
            // Bu mantık aslında QueryBuilder'ın özel türevlerinde veya bir QueryGrammar sınıfında olmalıdır.
            if (isset($this->parts['limit'])) {
                $sql[] = "LIMIT " . $this->parts['limit'];
            }
            if (isset($this->parts['offset'])) {
                $sql[] = "OFFSET " . $this->parts['offset'];
            }
        }

        return ['sql' => implode(' ', $sql), 'params' => $this->params];
    }
}

Yukarıdaki örnekte build() metodunda LIMIT ve OFFSET kısmı için bir yorum bulunmaktadır. Bu, sürücü bilinçli tasarımın en net göstergelerinden biridir. MySQL ve PostgreSQL, LIMIT ve OFFSET sentaksını doğrudan desteklerken, SQL Server gibi bazı veritabanları bu işlemleri farklı şekillerde (örneğin TOP anahtar kelimesi veya ROW_NUMBER() pencere fonksiyonu ile) yapar. Bu durumu yönetmek için, GenericQueryBuilder sınıfından türeyen MySqlQueryBuilder, PostgreSqlQueryBuilder veya SqlServerQueryBuilder gibi sınıflar oluşturulabilir. Her türev sınıf, kendi veritabanının spesifikasyonlarına uygun build() metodunu veya ayrı bir QueryGrammar (sorgu grameri) sınıfını kullanarak SQL çıktısını üretecektir. Bu sayede, uygulamanızın üst katmanları aynı QueryBuilder arayüzünü kullanmaya devam ederken, altta yatan veritabanı karmaşıklığı soyutlanmış olur.

Varlık Yönetimi ve Değişim Takibi (Unit of Work) Nasıl Sağlanır?

Unit of Work (İş Birimi) deseni, bir iş akışı veya işlem sırasında yapılan tüm değişiklikleri (yeni nesneler oluşturma, mevcutları güncelleme, silme) tek bir "birim" olarak izler. Bu değişiklikler, işlemin sonunda tek bir veritabanı işlemi (commit) olarak uygulanır. Bu desenin temel faydaları şunlardır:

• Tutarlılık: Tüm değişiklikler başarılı bir şekilde uygulanır veya hiçbiri uygulanmaz, bu da veritabanı tutarlılığını sağlar.
• Performans: Birçok küçük veritabanı işlemi yapmak yerine, değişiklikler toplanır ve tek bir toplu işlemde veritabanına gönderilir. Bu, özellikle birçok varlığın aynı anda değiştirildiği senaryolarda performansı artırır.
• Basitleştirme: Geliştiricilerin her değişiklik için manuel olarak INSERT, UPDATE veya DELETE sorgusu yazmak zorunda kalmadan varlıklarla çalışmasını sağlar.

Bir UnitOfWork'ün temel işlevleri şunları içerir:

1. Yeni Kayıtları İzleme: Henüz veritabanına kaydedilmemiş varlıkları kaydeder.
2. Değiştirilmiş Kayıtları İzleme: Mevcut olup, özellikleri değiştirilmiş varlıkları kaydeder.
3. Silinecek Kayıtları İzleme: Veritabanından silinmesi gereken varlıkları kaydeder.

Basit bir UnitOfWork yapısı:

class UnitOfWork
{
    private DatabaseDriverInterface $driver;
    private array $newEntities = [];
    private array $dirtyEntities = []; // Değiştirilmiş varlıklar
    private array $removedEntities = [];
    private array $entityMappers = []; // Varlık türüne göre DataMapper'ları tutar

    public function __construct(DatabaseDriverInterface $driver)
    {
        $this->driver = $driver;
    }

    public function registerMapper(string $entityClassName, DataMapperInterface $mapper): void
    {
        $this->entityMappers[$entityClassName] = $mapper;
    }

    public function registerNew(object $entity): void
    {
        $this->newEntities[] = $entity;
    }

    public function registerDirty(object $entity): void
    {
        // Gerçek bir UoW'de, bir varlığın gerçekten değişip değişmediğini kontrol etmek için
        // orijinal halini saklamak gerekir. Basitlik adına burada direkt ekliyoruz.
        $this->dirtyEntities[] = $entity;
    }

    public function registerRemoved(object $entity): void
    {
        $this->removedEntities[] = $entity;
    }

    public function commit(): void
    {
        $this->driver->beginTransaction();
        try {
            // Yeni varlıkları kaydet
            foreach ($this->newEntities as $entity) {
                $mapper = $this->getMapperForEntity($entity);
                $data = $mapper->mapObjectToRow($entity);
                $query = "INSERT INTO " . $this->getTableName($entity) . " (" . implode(', ', array_keys($data)) . ") VALUES (:" . implode(', :', array_keys($data)) . ")";
                $this->driver->execute($query, $data);
                // Eğer varlığın bir ID'si yoksa, yeni oluşturulan ID'yi atayabiliriz.
                if (method_exists($entity, 'setId') && $entity->getId() === null) {
                    $entity->setId((int)$this->driver->lastInsertId());
                }
            }

            // Değiştirilmiş varlıkları güncelle
            foreach ($this->dirtyEntities as $entity) {
                $mapper = $this->getMapperForEntity($entity);
                $data = $mapper->mapObjectToRow($entity);
                // ID değerini dışarıda bırakıp WHERE koşulunda kullan
                $id = $entity->getId();
                unset($data['id']); // Eğer mapObjectToRow id'yi döndürüyorsa
                $setParts = [];
                foreach ($data as $key => $value) {
                    $setParts[] = "{$key} = :{$key}";
                }
                $query = "UPDATE " . $this->getTableName($entity) . " SET " . implode(', ', $setParts) . " WHERE id = :id";
                $this->driver->execute($query, array_merge($data, ['id' => $id]));
            }

            // Silinecek varlıkları sil
            foreach ($this->removedEntities as $entity) {
                $query = "DELETE FROM " . $this->getTableName($entity) . " WHERE id = :id";
                $this->driver->execute($query, ['id' => $entity->getId()]);
            }

            $this->driver->commit();
            $this->clear(); // İşlemler bittikten sonra izlenen varlıkları temizle
        } catch (\Exception $e) {
            $this->driver->rollBack();
            throw $e;
        }
    }

    private function clear(): void
    {
        $this->newEntities = [];
        $this->dirtyEntities = [];
        $this->removedEntities = [];
    }

    private function getMapperForEntity(object $entity): DataMapperInterface
    {
        $className = get_class($entity);
        if (!isset($this->entityMappers[$className])) {
            throw new \RuntimeException("Entity için DataMapper bulunamadı: " . $className);
        }
        return $this->entityMappers[$className];
    }

    private function getTableName(object $entity): string
    {
        // Basit bir isimlendirme kuralı: User -> users
        // Gerçek bir ORM'de bu, Entity'nin bir özelliği veya konfigürasyondan gelir.
        $className = (new \ReflectionClass($entity))->getShortName();
        return strtolower($className) . 's';
    }
}

Bu UnitOfWork, varlıkların durumunu izler ve commit() çağrıldığında, DatabaseDriverInterface'i kullanarak ilgili veritabanı işlemlerini gerçekleştirir. Bu sayede, iş mantığı katmanınız doğrudan veritabanı işlemleriyle uğraşmak zorunda kalmaz, sadece varlık nesnelerini değiştirir ve UnitOfWork'e bildirir. Bu yaklaşım, karmaşık iş akışlarında bile veri bütünlüğünü ve performansı korumaya yardımcı olur. Ayrıca, transaction yönetimi sayesinde olası hatalarda tüm değişikliklerin geri alınmasını sağlar.

Gerçek Dünya Senaryosu: E-ticaret Projesinde Sürücü Bilinçli ORM Kullanımı

Sürücü bilinçli bir ORM mimarisinin gerçek değerini anlamak için, bir e-ticaret platformu senaryosunu inceleyelim. Diyelim ki, yeni bir e-ticaret platformu geliştiriyorsunuz. Başlangıçta, düşük maliyet ve geliştirme kolaylığı nedeniyle MySQL veritabanını tercih ettiniz. Ancak işler büyüdükçe ve platform daha fazla kullanıcıya ulaştıkça, performans ve ölçeklenebilirlik endişeleriyle birlikte, bazı müşterilerinizin şirket içi altyapıları gereği PostgreSQL veya hatta SQL Server kullanma talepleri ortaya çıkıyor. Eğer manuel SQL sorguları yazmış olsaydınız, bu durum projenizin veri erişim katmanını tamamen yeniden yazma kabusunu beraberinde getirirdi.

Sürücü bilinçli ORM mimarimiz sayesinde, bu geçiş oldukça yönetilebilir hale gelir. Temelde, veritabanı sürücüleri (MySqlDriver, PostgreSqlDriver, SqlServerDriver) aynı DatabaseDriverInterface'i uyguladığından ve Query Builder'ımız ile Data Mapper'larımız bu soyutlamaya bağımlı olduğundan, veritabanı değişikliği sadece bir konfigürasyon değişikliğine indirgenir. Örneğin, config.php dosyanızda sadece kullanmak istediğiniz sürücüyü ve bağlantı ayarlarını belirtmeniz yeterlidir:

// config.php
return [
    'database' => [
        'driver' => 'mysql', // veya 'postgresql', 'sqlserver'
        'mysql' => [
            'host' => 'localhost',
            'dbname' => 'ecommerce_db',
            'user' => 'root',
            'pass' => 'password',
            'charset' => 'utf8mb4'
        ],
        'postgresql' => [
            'host' => 'localhost',
            'dbname' => 'ecommerce_pg_db',
            'user' => 'pguser',
            'pass' => 'pgpassword',
            'charset' => 'utf8'
        ],
        // ... diğer sürücüler
    ]
];

Uygulamanızın başlangıç noktasında (örneğin bir Dependency Injection konteyneri kullanarak), bu konfigürasyona göre uygun sürücüyü dinamik olarak yükleyebilirsiniz:

// Uygulama başlangıcı
$config = require 'config.php';
$driverType = $config['database']['driver'];
$driverConfig = $config['database'][$driverType];

$driver = match ($driverType) {
    'mysql' => new MySqlDriver(),
    'postgresql' => new PostgreSqlDriver(),
    // ...
    default => throw new \InvalidArgumentException("Desteklenmeyen veritabanı sürücüsü: " . $driverType),
};
$driver->connect($driverConfig);

$queryBuilder = new GenericQueryBuilder($driver); // veya sürücüye özel QueryBuilder
$userDataMapper = new UserDataMapper();
$userRepository = new UserRepository($driver, $userDataMapper, $queryBuilder);
$unitOfWork = new UnitOfWork($driver);
$unitOfWork->registerMapper(User::class, $userDataMapper);

// Kullanıcı işlemleri
$users = $userRepository->findAll();
foreach ($users as $user) {
    echo $user->getUsername() . "\n";
}

$newUser = new User(null, "new_user", "new@example.com", new \DateTimeImmutable());
$userRepository->add($newUser); // UserRepository içinden UnitOfWork'e kaydolur
$unitOfWork->commit();

Bu senaryoda, bir kullanıcının ürün sipariş etme akışını düşünelim: Kullanıcı sipariş verir, stok güncellenir, ödeme kaydı oluşturulur. Tüm bu işlemler, UnitOfWork içinde bir veritabanı transaction'ı olarak yönetilir. Eğer stokta yeterli ürün yoksa veya ödeme başarısız olursa, UnitOfWork tüm değişiklikleri geri alır ve veritabanının tutarlı kalmasını sağlar. Ayrıca, SQL Server'ın TOP sentaksına ihtiyaç duyduğunuz bir performans kritik sorgu varsa, sadece SqlServerQueryBuilder sınıfındaki limit() veya build() metodunu bu spesifik sentaksı üretecek şekilde özelleştirmeniz yeterlidir. Uygulamanızın diğer katmanları bu değişiklikten etkilenmez. Bu esneklik, uzun vadeli projelerde sürdürülebilirliği ve adaptasyonu inanılmaz derecede kolaylaştırır.

@media screen and (max-width: 768px) {
  .responsive-table table,
  .responsive-table thead,
  .responsive-table tbody,
  .responsive-table th,
  .responsive-table td,
  .responsive-table tr {
    display: block;
  }
  .responsive-table thead tr {
    position: absolute;
    top: -9999px;
    left: -9999px;
  }
  .responsive-table td {
    border: none;
    border-bottom: 1px solid #eee;
    position: relative;
    padding-left: 50%;
    text-align: right;
  }
  .responsive-table td:before {
    position: absolute;
    top: 6px;
    left: 6px;
    width: 45%;
    padding-right: 10px;
    white-space: nowrap;
    text-align: left;
    font-weight: bold;
    content: attr(data-label); /* Her td için özel bir etiket */
  }
}
  

Gelişmiş Konular ve Optimizasyonlar: ORM'inizi Nasıl Daha Güçlü Hale Getirirsiniz?

Temiz ve sürücü bilinçli bir ORM mimarisi oluşturmak harika bir başlangıçtır, ancak gerçek dünya uygulamalarında performans, ölçeklenebilirlik ve esneklik gibi konuları ele almak için daha ileri düzey tekniklere ihtiyaç duyulur. Bu bölümde, ORM'inizi daha güçlü ve verimli hale getirecek bazı gelişmiş konuları ve optimizasyonları inceleyeceğiz.

Önbellekleme (Caching) Nasıl Entegre Edilir?

Veritabanı işlemleri genellikle uygulamanın en yavaş kısımlarından biridir. Sıkça erişilen ancak nadiren değişen veriler için önbellekleme (caching) kullanmak performansı önemli ölçüde artırabilir. Bir ORM'e önbellekleme entegre etmenin iki ana seviyesi vardır:

1. Birinci Seviye Önbellek (First-Level Cache): Genellikle Unit of Work içinde bulunur ve bir HTTP isteği süresince aynı varlığın birden fazla kez veritabanından çekilmesini engeller. Eğer bir varlık zaten Unit of Work tarafından izleniyorsa, veritabanına gitmeden doğrudan önbellekten döndürülür.
2. İkinci Seviye Önbellek (Second-Level Cache): Birden fazla HTTP isteği veya tüm uygulama boyunca önbelleklenen verilerdir. Redis, Memcached veya APCu gibi harici bir önbellek deposu kullanılarak uygulanır. Özellikle sık okunan ve nadiren yazılan veriler (örneğin, ürün kategorileri, ayarlar, popüler ürün listeleri) için çok etkilidir.

İkinci seviye önbellekleme entegrasyonu için, ORM'iniz, bir varlığı veritabanından çekmeden önce önbelleği kontrol etmeli, önbellekte yoksa veritabanından çekip önbelleğe almalı ve sonra döndürmelidir. Varlık güncellendiğinde veya silindiğinde, ilgili önbelleğin temizlenmesi (invalidasyon) kritik önem taşır. Önbellek entegrasyonu, Repository katmanında veya doğrudan QueryBuilder içinde bir önbellek servisi (CacheInterface) enjekte edilerek yapılabilir.

interface CacheInterface
{
    public function get(string $key): mixed;
    public function set(string $key, mixed $value, int $ttl = 0): bool;
    public function delete(string $key): bool;
}

// Bir Repository içinde önbellek kullanımı
class ProductRepository
{
    private DatabaseDriverInterface $driver;
    private ProductDataMapper $mapper;
    private QueryBuilderInterface $queryBuilder;
    private CacheInterface $cache; // Cache servisi

    public function __construct(DatabaseDriverInterface $driver, ProductDataMapper $mapper, QueryBuilderInterface $queryBuilder, CacheInterface $cache)
    {
        $this->driver = $driver;
        $this->mapper = $mapper;
        $this->queryBuilder = $queryBuilder;
        $this->cache = $cache;
    }

    public function findById(int $id): ?Product
    {
        $cacheKey = "product_{$id}";
        $cachedProductData = $this->cache->get($cacheKey);

        if ($cachedProductData) {
            return $this->mapper->mapRowToObject($cachedProductData);
        }

        $query = $this->queryBuilder->select()->from('products')->where('id', '=', $id)->build();
        $result = $this->driver->query($query['sql'], $query['params']);

        if (empty($result)) {
            return null;
        }

        $product = $this->mapper->mapRowToObject($result[0]);
        $this->cache->set($cacheKey, $result[0], 3600); // 1 saat önbellekte tut
        return $product;
    }

    // Ürün güncellendiğinde veya silindiğinde önbelleği temizlemeyi unutmayın
    public function update(Product $product): void
    {
        // ... güncelleme işlemleri ...
        $this->cache->delete("product_{$product->getId()}");
    }
}

Lazy Loading ve Eager Loading Stratejileri Nelerdir?

İlişkili verileri (örneğin, bir kullanıcının siparişleri veya bir ürünün kategorileri) ne zaman yükleyeceğimiz, ORM performansını büyük ölçüde etkileyen önemli bir karardır. İki temel strateji vardır:

1. Lazy Loading (Tembel Yükleme): İlişkili veri, yalnızca erişildiğinde yüklenir. Örneğin, $user->getOrders() çağrıldığında, veritabanına bir sorgu gönderilir ve kullanıcının siparişleri yüklenir. Faydası, gereksiz verilerin yüklenmesini önlemesidir. Dezavantajı ise "N+1 problemi"dir: Bir liste içindeki her varlık için ilişkili veriye eriştiğinizde, N adet ek sorgu çalışır (N varlık sayısı + 1 ana sorgu). Bu, performansı ciddi şekilde etkileyebilir.
2. Eager Loading (Hevesli Yükleme): İlişkili veriler, ana varlıkla birlikte tek bir sorguda (genellikle JOIN kullanarak) veya ayrı ancak optimize edilmiş sorgularla önceden yüklenir. Örneğin, tüm kullanıcıları ve onların siparişlerini tek bir sorguda çekmek. Bu, N+1 sorununu önler ve genellikle daha iyi performans sunar. Ancak, her zaman tüm ilişkili veriye ihtiyacınız yoksa gereksiz veri yüklenmesine neden olabilir.

ORM'iniz, QueryBuilder aracılığıyla bu stratejileri desteklemelidir. Örneğin, QueryBuilder'a bir with() metodu ekleyerek eager loading'i etkinleştirebilirsiniz:

// Eager Loading örneği
$usersWithOrders = $userRepository->findAllWithOrders(); // Repository içinde with('orders') çağrılabilir
// Veya doğrudan QueryBuilder üzerinden:
// $queryBuilder->select(['u.*', 'o.*'])->from('users u')->leftJoin('orders o', 'u.id', '=', 'o.user_id')->build();

Bu, userRepository'nin findAllWithOrders() metodunun, kullanıcıları ve ilgili siparişlerini tek bir sorguda (JOIN ile) veya iki ayrı sorguda (birincisi tüm kullanıcılar için, ikincisi bu kullanıcıların ID'lerini kullanarak tüm siparişler için) çekmesini sağlar. Veritabanı sürücünüzün ve Query Builder'ınızın yeteneklerine bağlı olarak, en uygun eager loading yöntemini seçmelisiniz.

Çoklu Veritabanı Desteği ve Dinamik Sürücü Seçimi Nasıl Yapılır?

Bazı karmaşık uygulamalar, farklı modüller veya mikro servisler için birden fazla veritabanı kullanabilir. Örneğin, kullanıcı yönetimi için bir veritabanı, ürün kataloğu için başka bir veritabanı. Sürücü bilinçli ORM'imiz, bu senaryoyu kolayca yönetebilir. Yapılandırma dosyanızda birden fazla veritabanı bağlantısı tanımlayabilir ve daha sonra çalışma zamanında veya Dependency Injection (DI) konteyneri aracılığıyla doğru bağlantıyı enjekte edebilirsiniz.

// config.php (Çoklu veritabanı yapılandırması)
return [
    'databases' => [
        'default' => [
            'driver' => 'mysql',
            'host' => 'localhost',
            'dbname' => 'main_db',
            'user' => 'root',
            'pass' => 'password',
            'charset' => 'utf8mb4'
        ],
        'reporting' => [ // Raporlama için ayrı bir PostgreSQL veritabanı
            'driver' => 'postgresql',
            'host' => 'report_db_server',
            'dbname' => 'reports',
            'user' => 'reportuser',
            'pass' => 'reportpass',
            'charset' => 'utf8'
        ]
    ]
];

// Uygulama başlangıcı veya bir service provider içinde
class DatabaseConnectionManager
{
    private array $connections = [];
    private array $config;

    public function __construct(array $config)
    {
        $this->config = $config['databases'];
    }

    public function getConnection(string $name = 'default'): DatabaseDriverInterface
    {
        if (!isset($this->connections[$name])) {
            $dbConfig = $this->config[$name];
            $driver = match ($dbConfig['driver']) {
                'mysql' => new MySqlDriver(),
                'postgresql' => new PostgreSqlDriver(),
                default => throw new \InvalidArgumentException("Desteklenmeyen sürücü: " . $dbConfig['driver']),
            };
            $driver->connect($dbConfig);
            $this->connections[$name] = $driver;
        }
        return $this->connections[$name];
    }
}

// Kullanım örneği
$dbManager = new DatabaseConnectionManager(require 'config.php');
$mainDbDriver = $dbManager->getConnection('default');
$reportDbDriver = $dbManager->getConnection('reporting');

// Ana veritabanından kullanıcı çek
$userRepository = new UserRepository($mainDbDriver, new UserDataMapper(), new GenericQueryBuilder($mainDbDriver));
$users = $userRepository->findAll();

// Raporlama veritabanından özel rapor çek
// Bunun için ayrı bir ReportRepository ve ReportDataMapper gerekebilir
$reportQueryBuilder = new GenericQueryBuilder($reportDbDriver);
$monthlyReports = $reportDbDriver->query($reportQueryBuilder->select()->from('monthly_reports')->build()['sql']);

Bu yaklaşım, uygulamanızın farklı bölümlerinin, ihtiyaçlarına en uygun veritabanı çözümünü kullanmasına olanak tanır. Her veritabanı bağlantısı, kendi sürücüsü ve yapılandırmasıyla izole edilir, bu da sistemin genel esnekliğini ve bakım kolaylığını artırır. Gelişmiş optimizasyonlar ve esneklik, ORM'inizin sadece bir veritabanı soyutlama aracı olmaktan çıkıp, uygulamanızın veri katmanının stratejik bir parçası haline gelmesini sağlar.

Sonuç: Temiz ve Sürücü Bilinçli ORM'in Geleceği

Bu makale boyunca, PHP'de temiz ve sürücü bilinçli bir ORM mimarisinin neden gerekli olduğunu, nasıl tasarlanacağını ve gerçek dünya senaryolarında nasıl uygulanacağını detaylı bir şekilde inceledik. Gördüğümüz gibi, bu yaklaşım sadece kod tekrarını azaltmakla ve geliştirici üretkenliğini artırmakla kalmıyor, aynı zamanda güvenlik, bakım kolaylığı ve en önemlisi veritabanı bağımsızlığı sağlayarak uygulamanızın geleceğe dönüklüğünü garanti altına alıyor. Bir e-ticaret platformunda farklı veritabanı gereksinimlerine nasıl kolayca adapte olunabileceğini, sorgu oluşturucuların ve veri eşleyicilerin bu süreçte nasıl merkezi bir rol oynadığını ele aldık. Ayrıca, önbellekleme, lazy/eager loading ve çoklu veritabanı desteği gibi gelişmiş optimizasyonlarla ORM'inizi daha da güçlü hale getirme yollarını keşfettik.

Temiz bir mimari, sorumlulukların net bir şekilde ayrıştırılmasını gerektirir: veritabanı sürücüleri, sorgu oluşturucular, veri eşleyiciler, varlıklar ve depolar. Sürücü bilinçli olmak ise, bu katmanların temel veritabanı lehçelerini ve özelliklerini anlayıp soyutlayarak, PHP uygulamanızın PostgreSQL'den MySQL'e, oradan SQL Server'a veya başka bir ilişkisel veritabanına sorunsuz bir şekilde geçiş yapabilmesini sağlar. Bu mimari, test edilebilirliği artırır, çünkü her bileşen kendi başına test edilebilir ve bağımlılıklar enjeksiyon yoluyla yönetilir. Gelecekte, NoSQL veritabanlarının yükselişiyle birlikte, bu tür soyutlamaların NoSQL çözümlerine adapte edilmesi veya GraphQL gibi yeni API paradigmalarıyla entegrasyonu, ORM benzeri araçların evriminde yeni ufuklar açacaktır. Önemli olan, veri erişim katmanını her zaman uygulamanızın geri kalanından bağımsız ve esnek tutmaktır. Bu sayede, teknolojiler değiştikçe uygulamanız da onlarla birlikte evrilebilir ve iş ihtiyaçlarına hızla yanıt verebilir.

Sıkça Sorulan Sorular

Soru 1: ORM kullanmak her zaman iyi bir fikir midir?

Cevap: Çoğu durumda evet, çünkü üretkenliği, bakımı ve güvenliği artırır. Ancak, çok performans kritik ve karmaşık sorguların olduğu durumlarda veya veritabanının spesifik özelliklerinden faydalanmak istediğinizde, doğrudan SQL yazmak daha iyi bir seçenek olabilir. ORM'ler, performans overhead'i getirebilir, bu nedenle her zaman dengeli bir yaklaşım benimsemek önemlidir.

Soru 2: Sürücü bilinçli mimarinin ana faydası nedir?

Cevap: Ana faydası, veritabanı sağlayıcısından bağımsızlık sağlamasıdır. Uygulamanızın temel iş mantığı, altta yatan veritabanının türünü bilmek zorunda kalmaz. Bu, gelecekte farklı bir veritabanına geçiş yapmanız gerektiğinde veya birden fazla veritabanı türünü desteklemeniz gerektiğinde büyük bir esneklik ve kolaylık sunar.

Soru 3: ORM'de performans sorunlarını nasıl giderebilirim?

Cevap: Performans sorunlarını gidermek için önbellekleme (birinci ve ikinci seviye), doğru yükleme stratejileri (eager loading ile N+1 problemini çözme), indekslerin etkin kullanımı ve gerektiğinde ORM'i atlayarak doğrudan optimize edilmiş SQL sorguları çalıştırmak gibi yöntemler kullanabilirsiniz. Ayrıca, iyi tasarlanmış bir veritabanı şeması ve düzenli sorgu optimizasyonu da kritiktir.

Soru 4: Kendi ORM'imi yazmalı mıyım, yoksa mevcut bir kütüphaneyi mi kullanmalıyım?

Cevap: Çoğu durumda, Doctrine, Eloquent gibi mevcut ve olgun ORM kütüphanelerini kullanmak daha mantıklıdır. Bu kütüphaneler, yüzlerce geliştiricinin tecrübesiyle şekillenmiş, geniş özellik setleri sunan ve iyi test edilmiş çözümlerdir. Kendi ORM'inizi yazmak, genellikle zaman alıcı ve karmaşık bir iştir ve ancak çok spesifik ihtiyaçlarınız varsa veya öğrenme amacıyla yapılmalıdır.

Soru 5: Hangi durumlarda raw SQL tercih edilmeli?

Cevap: ORM'in sunduğu soyutlama katmanının performans veya esneklik açısından yetersiz kaldığı özel durumlar (örneğin, çok karmaşık raporlama sorguları, depolanmış prosedürlerin çağrılması veya veritabanına özel optimize edilmiş fonksiyonların kullanılması) için raw SQL tercih edilebilir. Bu gibi durumlarda, yine de PDO gibi güvenli yöntemlerle parametre bağlamayı kullanarak SQL enjeksiyonu riskinden kaçınmalısınız. Temiz bir ORM mimarisinde, raw SQL'i doğrudan Driver Layer üzerinden çalıştırmak için bir mekanizma her zaman bulunmalıdır.