Problem:

Uygulamamız Oracle veri tabanı ile çalışıyor. Ama şirketin yaptığı bir anlaşma sonrasında bir yıl sonra Oracle yerine SQL’e geçiş yapmak gerekiyor. Aynı zamanda SQL’e yapılan geçiş belki bir kaç yıl sonra tekrar Oracle’a dönüş ile de sonuçlanabilir. Yarın bir gün farklı bir veri tabanı da gelebilir. Buda bizim için ayrı bir problem.

Çözüm :

Her veri tabanı kendine özgü bir “connection, command” yapısı barındırıyor. Yani bir SQL sağlayıcısı işleyeceği “command” için öncelikle bir “connection” ihtiyaç duyuyor. Bir “connection” olmadan “command” olmayacağından bunları bir bütün olarak değerlendiriyoruz. Burada devreye “Abstract Factory Pattern” giriyor.


Bizim iki adet DB sağlayıcımız olacak. Oracle sağlayıcımızı ele alırsak eğer içerisinde “OracleConnection, OracleCommand” ile birlikte bir oluşum gösterdiğini göreceğiz.

Kafanızda daha da canlanması açısından bir örnek daha vereyim. Bir salon takımını düşünün içerisinde bir adet üç kişilik, bir adet iki kişilik ve bir adet tek kişi koltuk barındırır.

Bu ürün ailesini tek bir isim üzerinden aldığınızda içinde alt ürünleri barındırır. Abstract Factory’de bizim için bunu yapar, biz ana ürün talebimizde bulunuruz. O bize ilişkili alt ürünleri getirir.


Commands, Connections for Providers

Bizim ana ürünümüz bir DB sağlayıcı(Oracle ya da SQL), connection ve command ile beraber bir DB sağlayıcı ortaya çıkıyor diye planladık.
Burada SQLProvider oluşturmayı örnek alalım.

blank

SQLProvider “BaseProvider”dan “CreateCommand” ve “CreateConnection” methodlarını ovverride etmek zorunda olduğu için sağlayıcının bir connection ve bu connection’ı kullanan command’ının olduğundan emin oluyoruz.

Peki SQLProvider ve OracleProvider oluşturduk, hangisinin çalışma anında sorgularımıza yanıt vereceği kararını nerede vereceğiz ?
Bir önceki yazımızda anlattığımız “Factory Method” tasarım desenini kullanarak çözüm bulacağız.

ProviderFactoryMethod adında bir sınıf oluşturduk ve bu sıfına gelecek parametreye göre SQLProvider mı yoksa OracleProvider mı ? Bunun kararı vermiş olacağız. Reflection kullanımı ya da swich case kullanımı tercih edilebilir.

blank

Aynı zamanda gelen parametrelerin her hangi bir değere denk gelmemesi durumunda uygulamanın defaultProvider seçimini oluşturmakda işimize yarıyacak bir nokta.

Son olarak ProviderFactoryMethod ile konuşacak ve sorgularımıza yöneticilik yapacak bir sınıfa ihtiyacımız var. Bu sınıf sağlayıcıya karar verecek parametreyi bulup ProviderFactoryMethod ile konuşacak ve sağlayıcıyı oluşturacak.

blank

Oluşturulan ProviderManager select sorgusu geldiğinde ilgili bağlantıyı oluşturarak komutunda bu bağlantıya bağlı olarak çalışmasını sağlar ve işlemi sonuçlandırır.

blank
Query test

Buradaki sorgulama yapısı tabiki sağlayıcıya göre değişkenlik gösterecektir. Kendi sınıfları içerisinde bu özelleştirmelerin yapılması gerekiyor. Benim göstermek istediğim bu tarzda bir sorunu “Abstract Factory Pattern” ile nasıl çözümleneceği göstermekti.

Repo url :
https://github.com/gsmtcnr/DesignPattern.Creational.AbstractFactory

Leave a Reply

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir