AllMyListsLE yazılımının kökenleri 2011 yılında geliştirmeye başladığım Windows Forms tabanlı AllMyLists yazılımına dayanmaktadır. Bu ilk geliştirmeyi WPF tabanlı AllMyListsWPF uygulaması izlemiş, ardından MVVM mimarisini denemeye çalıştığım AllMyListsWPFMVVM yazılımını geliştirmeye başlamıştım. Daha sonra 2012 yılında bir Windows 8 Store uygulaması olan AllMyListsMetro'yu bütünüyle yeni bir mimari üzerinde geliştirdim (https://meminmutlu.wordpress.com/personalis/pim-projects/).
2013 yılında "Yaşam Boyu Öğrenme Deneyimlerinin Yönetimi Amacıyla Bir Dijital Yaşam Günlüğü Sisteminin Geliştirilmesi ve Uygulanması" isimli projede yaşam ve öğrenme deneyimlerinin yönetimi için bir yazılıma gereksinimi duyulduğunda AllMyListsWPFMVVM tasarımını temel alarak AllMyListsLE yazılımını geliştirmeye başladım.(http://personalinformationsystems.blogspot.com/2013/02/development-and-implementation-of.html)
AllMyLists yazılımı bir ana pencereye yerleştirilmiş birer ağaç, ızgara ve zengin metin kutusu denetimleri üzerinde çalışmaktaydı. Tüm kodlar ana sayfaya yerleştirilmişti ve sayfadaki denetimlere ait olaylar ana sayfada işlenmekteydi.
AllMyListsWPF'de denetimler Windows Forms yapısından XAML'e taşınmış fakat işleyiş aynı bırakılmıştı. Tüm kodlar ana sayfada yeralmaya devam etmişti. XAML teknolojisi Windows Forms'un rijid yapısına göre büyük tasarım esnekliği sağlamıştı.
AllMyListsWPFMVVM'de ise denetimlerin kendi kodlarını kendi içlerinde barındıracak şekilde düzenlenmeye çalışılmıştır. Bu amaçla ana sayfada bulunan ve denetimlerin altında çalışması daha mantıklı olan tüm kodlar denetimlere birer method olarak taşınmış ve denetimler de birer "UserControl" haline getirilerek birer kopyaları (ilgili "Grid" ler ve "GridSplitter" lar dışında boş olan) ana pencereye yerleştirilmişlerdir.
AllMyListsLE yazılımına başlandığında ise ilk yapılan işlem tüm veritabanı işlemlerinin ayrı bir sınıfa aktarılması olmuştur. Böylece bütün denetimlerin kullandığı ortak bir veri modeli oluşturulmuştur. Diğer taraftan yazılıma LifeLogging görüntülerinin görüntülenmesiyle ilgili yeni "UserControl" ler eklenmiştir. Bu denetimler görüntülerin yerleştirildiği bir görüntü listesi ile verilen bir güne ait görüntülerin hangi cihaza ait olduğunu belirtmek amacıyla kullanılan bir cihaz listesidir.Diğer taraftan yazılımın yapısı düğümleri kullanıcı tarafından oluşturulan "MyList" ve düğümleri kaydedilmiş görüntü klasörlerinden elde edilen "LifeLog" şeklinde iki ayrı ağaç yapısını işleyecek hale dönüştürülmüştür.
Bir süre sonra "MainWindow" ve kendisine yerleştirilmiş olan "UserControl" ler arasında yoğun bir bağımlılık bulunduğu, denetimlerden ana penceredeki değişkenlere ve yöntemlere erişildiği hatta denetimlerin ana pencere üzerinden diğer denetimlere eriştiği gözlenmiştir. Örneğin kullanıcı ağacın bir düğümünü seçtiğinde, ağaç nesnesi cihaz listesi nesnesine erişmekte, cihaz listesi nesnesinden bir cihaz seçildiğinde ise cihaz listesi nesnesi görüntü listesini etkinleştirmektedir.
Bu durum dolaşıklık oluşturmakta ve nesne yaklaşımlı programlama mantığıyla çelişmektedir. Bu sorunu aşmak amacıyla ayrıntılı bir tarama yapılmış ve yazılımın tümünde sadece ana pencereden üzerinde yerleşik bulunan kullanıcı denetimlerine erişimin bulunduğu, denetimlerden ana sayfanın ya da diğer denetimlerin çağrılmadığı duruma kavuşuncaya değin bir ayıklama işlemi gerçekleştirilmiştir. Bu amaçla denetimlere çok sayıda "Event", "Field" ve "Property" eklenmiştir. Böylece bir denetimin diğer bir denetime doğrudan erişmesi yerine kendisine ait özel bir "Event" ı tetiklemesi, bu "Event" ı yakalayan ana pencerenin hedefteki denetime erişmesi şeklinde bir geçişkenlik kullanılmıştır. Veritabanı nesnesinin ana pencere üzerinde çağrılması yerine denetimlerde gerekli olan yerlerde "Private" veritabanı nesnelerinin tanımlanması yoluna gidilmiştir.
Yukardaki örnek bu durumda şu şekilde çalışmaya başlamıştır: Ağacın bir düğümü seçildiğinde bir olay tetiklenir. Ana pencere bu olayı yakalar ve cihaz listesini etkinleştirir. Cihaz listesi nesnesi bir öğe seçildiğinde bir olayı tetikler. Ana pencere bu olayı yakalar ve görüntü listesini etkinleştirir. Böylece alt denetimler kendi aralarında iletişimi ana pencere üzerinden sağlarlar.
Nisan sonu, Mayıs ortası arasında yapılan ayıklama sonucunda yaklaşık 450 dolaşık çağrı yazılımdan kaldırılmıştır. Böylece AllMyListsLE yazılımında karmaşıklık ortadan kaldırılmış, basit ve anlaşılır bir mimari elde edilmiştir. Gelinen aşamada denetimlerin veri modeline bağımlılığı dışında diğer nesnelere olan bağımlılığı kalmamıştır. Bir sonraki adımda denetimler ile veri modeli arasında bağımsızlık sağlanacak ve bu süreç yazılımda MVVM mimarisine tam anlamıyla geçilene kadar devam edecektir.
Hiç yorum yok:
Yorum Gönder