Data Vinci 6 : Unit of Work

Tahmini Okuma Süresi: 5 dakika

Bir önceki yazıda tasarım desenlerinin gelişi güzel, yahut eksik tasarımla, yahut “büyük resim” görememekten ötürü “anti-pattern” haline bürünebileceğinden bahsetmiştim. Zaman zaman bu “uber” yaklaşımlar içinde bulundukları imkân ve şerâit içerisinde gaflet halini alabiliyor. Hâl böyle olunca bir takım ek bakış açıları katmak, camiada “Bottleneck” denen, varoşlarda “nabacaz la buna” şeklinde karşılık bulan sorun tanımlarına veya sorularına yeni ufuklar katmak gerekebiliyor. İşte bunların bir meyvesi alkışlarınızla karşınızda “Unit of Work”. Ünlü düşünür Martin Fowler ,Patterns of  Enterprise Application Architecture kitabında bu konuya değinmiş ve istikbalin nerde olduğuna dair işaretleri çakmıştır. Peki “Unit of Work” neye tepki olarak doğmuştur bunu açıklamaya çalışayım. Tasarım desenlerinden “repository” basit açıklama ile veritabanı işlemlerini -camiada (CRUD) diye anılan varoşlarda “dibiye yazarız kanka”şeklinde karşımıza çıkan-,  generic bir yapıya büründürmek için ortaya konulmuştur. Repository pattern kendi iç dinamikleriyle değerlendirildiğinde çok “şapşik” bir pattern olsa da, data access katmana yapılan erişimlerden ötürü “generic” olma özelliğini yitirmektedir. Bağımlılık oluşmaktadır.

Unit of Work ise bu CRUD işlemlerini yaparken objeleri hafızada tutma, değişikliklerini takip etme,  Yine camiada Bulk Insert olarak bilinen toplu kayıt işlemlerine aracılık etmek adına ortaya konulmuştur. Test Driven Development yaklaşımında unit testleri yönetebilir kılmak için CRUD işlemi yapılan sınıfın “wrapping” yapılması şeklinde ifade edilebilir.

Grafiğin Kaynağı: https://www.codeproject.com/articles/581487/unit-of-work-design-pattern

Unit of Work konusu Nhibernate, Entity Framework gibi ORM(Object Relational Mapping) gibi araçların kullanıldığı, veritabanı ile etkileşimde olan, -bir repository pattern kullanmasına da çok gerek yok- uygulamalar söz konusu ise farkında olunması gereken bir konu.

Unit of Work konusu irdelendiğinde, başarılı bir tasarım deseni olduğu fikri oluşur ki bu doğrudur. Bir önceki yazıda da farklı sistemler kurgulanırken tasarım kalıplarına ihtiyaç olduğundan ve bu sistemlerin illa ki “oop” başlığı altında yer alması gerekmediğinden bahsetmiştim. Kurumsal mimariler için önemli yaklaşımlardan birisi çalışan uygulamaların izolasyonlarının maksimum olmasıdır. Bir diğer deyiş ile “Loosely coupling” kavramına en yakın olmasıdır. Böylelikle entegrasyon noktalarındaki bağımlılıkların azalması hedeflenir.

Unit of Work pattern’in niyeti(intent), veritabanı işlemlerinde tek bir bağlantı üzerinden işletilmesi, in-memory obje kullanarak CRUD işlemlerin tek seferde icra edilmesi halk deyişiyle “gerekenin yapılması”, “at hafızaya, bellek bedava” yaklaşımıyla, her bir operasyonu “unit” olarak değerlendirip  tek bir transaction’da yönetilmesidir. UnitOfWork pattern’i icra eden sınıfın içerisine yazılacak olan değişikleri kaydet methodu, kullanılan ORM’nin değişiklikleri kaydet methodu veya CRUD işlemi her nasıl yapılıyor ise onun yerine geçmelidir. Yine benzer şekilde hata oluşmasında izlenecek Rollback mekanizması da UnitOfWork içerisine yerleştirilmelidir. Nispeten daha kısa olan bu yazıma son vermeden önce bir kaç referans olabilecek link önermek istiyorum.

Konu ile ilgili olarak müstesna insan Martin Fowler’ın eyyorlamaları : POEAA . Konu hakkında birinci ağızdan ne tarz fikirler çıkıyor görmek için Martin Fowler takip edilmesi gerekir.

Detaylı Türkçe kaynak için ise  değerli hocam Burak Selim Şenyurt‘un yazısını okumanızı tavsiye ederim : Entity Framework Generic Repository ve Unit of Work Uyarlaması . Kendisini birçok alanda kaleme aldığı birçok kıymetli yazısı mevcuttur. Benim yazılarıma vermiş olduğu destek bir kenara, yazılım topluluklarına senelerdir yapmış olduğu katkılardan ötürü ne kadar teşekkür etsem azdır.

Faydası olması dileklerimle.

keep_calm

Leave a Reply

Your email address will not be published. Required fields are marked *