Log4Net delete last N days files

Daha önceki yazımızda projemize nasıl Log4Net implemente edilir burada ki yazıda incelemiştik. Log4Net te bahsettiğimiz gibi bizim verdiğimiz kritere uygun boyutlarda belirttiğimiz klasör altında log dosyalarını saklıyordu. Peki ya o klasör altında aylarca yıllarca çok fazla log dosyası oluşur ve GB boyutunda yer kapladığı düşünülürse ne olacak??? "Hadi be sende GB boyutunda log nerde biriksin.." falan diyebilirsiniz ancak projenizin büyüklüğüne göre bunun olma olasılığı oldukta büyük bir ihtimal.
İşte bu gibi durumlardan kurtulmak için bir File Clear türünde bir manager yazmamız gerekmekte.

Akış şu şekilde olacak; Log4Net kendi işini yapıp loglarını dosyalara atmaya devam ederken uygulamanın her Application_Start adımında file clear manager çalışıp Log klasörüne gidip bakıcak. İçerisindeki dosyalardan son 2 haftadan daha eski tarihte oluşmuş dosyalar var ise gidip bu dosyaları silecek.

ilk olarak aşağıda oludğu gibi Log4NetFileCleanUpManager adında bir class oluşturuyoruz

public class Log4NetFileCleanUpManager
    {
        private DateTime _lastDateToKeepStoring;
        public Log4NetFileCleanUpManager()
        {
            _lastDateToKeepStoring = DateTime.Today.AddDays(-14);
        }

        public void CleanUp()
        {
            var repo = LogManager.GetAllRepositories().FirstOrDefault();

            if (repo == null)
                throw new NotSupportedException("Log4Net has not been configured yet !");

            var app = repo.GetAppenders().FirstOrDefault(x => x.GetType() == typeof(RollingFileAppender));
            if (app != null)
            {
                var appender = app as RollingFileAppender;
                string directory = Path.GetDirectoryName(appender.File);
                 CleanUp(directory);
           }
        }

        public void CleanUp(string logDirectory)
        {
            if (string.IsNullOrEmpty(logDirectory))
                throw new ArgumentException("logDirectory is missing");

            var dirInfo = new DirectoryInfo(logDirectory);
            if (!dirInfo.Exists)
                return;
 
            var fileInfos = dirInfo.GetFiles();
            if (fileInfos.Length == 0)
                return;
 
            foreach (var info in fileInfos)
            {
                if (info.CreationTime < _lastDateToKeepStoring)
                {
                    info.Delete();
                }
            }
        }
    }
Kod şu şekilde çalışıyor. Constructor da hangi tarihten sonraki kayıtları silineceği bilgisi veriliyor (Son 14) gün. CleanUp fonksiyonunda Log4Net için webconfigde tanımlı RollingFileAppender bulunuyor ve bunun için tanımlı log klasörünün directory si bulunup CleanUp(string logDirectory) metduna yollanıyor. Burada o klasörün içerisindeki dosyalarda teker teker gezinip oluşturulma tarihlerine bakıyor. Oluşturulma tarihi bizim belirttiğimiz tarihten önce ise o dosyayı siliyor.
 
 
Son olarak Application_Start metodunda aşağıdaki configurasyonu yapmamız gerekmekte.
XmlConfigurator.Configure();
var task = new Log4NetFileCleanUpManager(); 
task.CleanUp();
 

Log tutmak ne kadar önemli ise tuttuğumuz log'un yönetimi ve başa bela olmaması da o kadar önemlidir. Üstte de söylediğim gibi projenin büyüklüğüne göre onlarca GB boyutunda .txt dosyaları ansızın oluşabilir ve sonrasında down !

OraOledb Not enough storage is available to complete this operation.

There are like 100 questions and answers about this problem but none of them did solve my problem.

What I was was trying to do is getting blob data from oracle database using ado.net just like below code,

OleDbParameter returnValue = new OleDbParameter("v_PictureBlodData", OleDbType.LongVarBinary);


and when I try to execute the store procedure & query I was getting an error which sais "Not enough storage is available to complete this operation."

Most of the comments for this problem is about, server Ram capacity or Storage capacity. But I was really sure that my server had enough Ram and Storage capacity.

 

So, what solved my problem is just giving a size value for OleDbParameter which is 4000000

OleDbParameter returnValue = new OleDbParameter("v_PictureBlodData", OleDbType.LongVarBinary, 4000000);


If you guys are sure about your server capacity, you can check it by trying to give a size value for the parameter.

Log4Net İmplementasyonu

"Log uğrunda ölen olmadıktan sonra log değildir !!"

Önceki çalıştığım firmalardan birinde uzun soluklu bir bankacılık projesi geliştiriyorduk ve daha önce ilgilenen arkadaşlar bilirler ki development süreci oldukça meşakatlidir. Önce Dev de çalış sonra Test'e at sonra UAT e al sonra PROD a taşı orda testleri yap vs. vs. bir sürü ortam birsürü bug ve en önemlisi yüzlerce şöyle cümleler duyabilirsiniz "TEST te sıkıntı yok ama UAT de çalışmıyor yada sadece PROD da rastladığımız bir durum..." bu gibi durumlarda loglardan yürüyerek ilerlemek sorunun kaynağına en kısa sürede ulaşmanızı sağlayabilir. Tabi log alt yapınız var ise :) Ama bitmedi log altyapınızın olmasıda o loga bir bakış attığınızda ahanda tamam sorunu buldum diyebileceğiniz anlamına gelmeyebilir. Çok fazla yaşadığım bir olaydan bahsetmek istiyorum ve bir arkadaşımın bu olay sonrası projedeki Test Müh. arkadaşa söylediği bir cümle varki efsane :)

Birgün yine üstte bahsettiğim bankacılık projesinde dev yapıyorum ve ekip yaklaşık olarak 10 kişi falan (.net-ios-android-pm-tester vs.). Yine o sihirli cümle geldi ve test müh arkadaş android yazan arkadaşa "droidci arkadaş PROD da rastlanan bir hata varmış ve müşteri ilgili maddeyi JIRA da açmış ve logları paylaşmış. Sorunu kısa sürede çözebilir misin.." vs şeklinde bir cümle kurdu. Developer arkadaş JIRA yı açtı madde yi okudu ve loglara baktıktan sonra test müh arkadaşa "maddeyi bulamadım, müşteriye geri assign ediyorum.." gibi birşey söyledi ve test müh arkadaş da "ama nasıl bulamazsın loglarıda yollamışlar ki.. -%&?!?.." Bu cümleye atarlanan developer arkadaş işte o anda o efsane atasözünü söyledi. "Log uğrunda ölen olmadıktan sonra LOG değildir arkadaşım..!" Sonuç olarak ne oldu sizce ? Log var madde var ama çözüm için elde hiçbir şey yok. Yazılım projelerinde çok büyük öneme sahip olan log yapıları emin olun hayat kurtarır.  Çeşitli loglama türleri vardır. DBLog, FileLog vs gibi. Bu örnekte hemen hemen herkesin en azından duymuş olduğu Log4Net kütüpanesini kullanarak orta çaplı bir FileLog yapısı nasıl kurulur ondan bahsedicem. Log4Net için öncelikle Nugetten ilgili dosyayı indirip projemize kuruyoruz Install-Package log4net    Daha sonra aşağıda olduğu gibi ILog adında bir interface tanımlıyorum. Parametre olarak LogModel türünde bir obje alıyor olacak. Bu obje içerisinde loglamak istediğimiz alanlar mevcut olacak.

public class LogModel
    {
        public string ExcMessage{get;set;}
        public Exception ExceptionModel{get;set;}
      }

  public interface ILog
    {
        void Log(LogModel entry);
     }

Log4Net için WebConfig de birtakım ayarlar yapmamız gerekiyor. Bu ayarların kapsamı çok fazla ancak kısaca özetlemek gerekirse LogDosyalarının adlandırılması, LogDosyalarının bulunacağı path bilgisi, max kaç MB lık dosyalar tutulacak ve enfazla kaç dosya olmasına izin verilecek gibi bir çok LogConfig Settings diyebileceğimiz şey içermekte. Bu projedeki WebConfig dosyası asağıda olduğu şekildedir.

 

 <appender name="LogFileAppender" type="log4net.Appender.RollingFileAppender">

      <file value="LogFiles\\" />

      <appendToFile value="true" />

      <DatePattern value="yyyy\\\\MM\\\\dd'.day.logs.txt'" />

      <rollingStyle value="Date" />

      <maxSizeRollBackups value="7" />

      <param name="StaticLogFileName" value="false" />

      <layout type="log4net.Layout.PatternLayout">

        <conversionPattern value="%newline%date %newline%logger [%property{NDC}] %newline>> %message%newline" />

      </layout>

     </appender>

 

Şimdi sırada Loglama işlemini yönetecek bir Log4Manager' ihtiyacımız var. Burda yarın bir gün XManager YManager da tanımlayabiliriz. Bunun bir çok implementasyonu olabilir. Ben böyle birşey kullanmayı tercih ettim. ILog, IDisposable interfacelerinden türeyen Log4NetLogManager adında bir class yazıyoruz. Class ın içeriği aşağıdaki gibi olacaktır. 

 

 

public class Log4NetLogManager : ILog, IDisposable
    {
         private log4net.ILog log4Net;
         public Log4NetLogManager()
        {
            log4net.Config.DOMConfigurator.Configure();
            log4Net = log4net.LogManager.GetLogger(typeof(Log4NetLogManager));
        }
         public void Log(LogModel entry)
        {
            log4Net.Error(entry.ExpMessage, entry.ExceptionModel);
        }
         public void Dispose()
        {
            if (log4Net != null)
                log4Net.Logger.Repository.Shutdown();
        }
    }

 

İşlemlerimiz bu kadar. Bu saatten sonra tek yapmamız gereken bu manager'ı kullanan logic ler yazmaktır. Bir sonraki örneğimizde ASP.Net WebApi tarafında ExceptionHandling olaylarına girip yukarıda yazmış olduğumuz Manager'ı kullanan bir app yazacağız.

 

 

Post two

This post is just an example using Post List widget with image in the post body.

Post List widget should find first image in the post body and display it in the post list when this option selected in the widget admin.

Web Api Projesi Oluşturma

Şöyle bir örnek proje yapalım. TodoApi adında bir WebApi projemiz olsun ve bu Api'a bir tane controller tanımlayıp içerisine TodoList dönen bir metot yazalım.

İlk olarak Visual Studio açıyoruz ve File => New => Project diyoruz ve aşağıdaki görselde olduğu gibi Web kategorisine tıklayıp sonrada ASP.Net Web Application'ı seçiyoruz ve projenize bir isim verdikten sonra OK'e tıklıyoruz.

 

Daha sonra açılam ekrandan Empty kategorisini tıklayıp ekranın orta kısmında bulunan checkbox'lardan WebApi'ı seçiyoruz ve OK'e tıklıyoruz.

 

Artık solution'da projemiz hazır. Şimdi ilk olarak Models klasörü içerisine TodoItem isminde aşağıdaki gibi bir class tanımlayalım.

namespace TodoApi.Models
{
    public class TodoItem
    {
        public string Key { get; set; }
        public string Name { get; set; }
        public bool IsComplete { get; set; }
    }
}

Şimdi ise TodoController adında controller'ımızı tanımlayalım. Bunun için solution'da bulunan Controller klasörünün üzerine gelip sağ tıklayıp Add diyelim sonrasında açılan ekrandan Controller'ı seçelim ve Controller'a TodoController ismini verip OK'e tıklayalım.

Artık TodoController'ınıda oluşturduk şimdi sırada GetAllTodoItems isminde HTTPGET request'i atılabilen ve geriye List<TodoItem> dönen bir metot yazalım.

public class TodoController : ApiController
    {
        [HttpGet]
        public List<TodoItem> GetAllTodoItems()
        {
            var responseList = new List<TodoItem>
            {
                new TodoItem{
                    Key="SD2",
                    Name="Görev1",
                    IsComplete=true,
                },
                new TodoItem{
                    Key="SD11",
                    Name="Görev2",
                    IsComplete=true,
                },
                new TodoItem{
                    Key="SD251",
                    Name="Görev3",
                    IsComplete=true,
                },
                new TodoItem{
                    Key="SD8",
                    Name="Görev4",
                    IsComplete=true,
                },
                new TodoItem{
                    Key="SD01",
                    Name="Görev5",
                    IsComplete=true,
                },
                new TodoItem{
                    Key="SD42",
                    Name="Görev6",
                    IsComplete=true,
                },
            };

            return responseList;
        }

Api projemiz var. Şimdi gelin bu Api'a requestte bulunup ne response dönüyor onu görelim. Projeyi çalıştıralım ve her hangi bir rest client tool kullanarak aşağıdaki link'e requestte bulunalım.

  • http://localhost/api/Todo/GetAllTodoItems

Ben genelde Postman'i kullanıyorum ve aşağıdaki gibi Postman ile GET request'i atıyoruz.

 

Dönen response'a baktığımızda aşağıdaki gibi json formatında response geldiğini göreceğiz.

 

WebApi candır arkadaşlar ve servis tarafında geliştirme yapıyorsanız da çok ama çok önemlidir. Bir Microsoft yetkilisi bir konferansta şuna benzer bir cümle kurdu "Biz daha iyisini yapana kadar en iyisi bu !".

 

Web Api Projesine Cache Ekleme - OutPutCache

Server-side tarafında geliştirme yapan arkadaşlar bilirler ki request-response time ları çok büyük önem sarf etmektedir. Örnek olarak, bir muhasebe DB niz var ve her gün gece 23:59 da günlük raporlar giriliyor veya 3 dkka yeni kayıt girilen bir yapıda olabilir. İlgili tabloda şuana kadar 200 bin kayıt girilmiş diyelim. select * from Raporlar dediniz ve size 200 bin kayıtı ortalama 15 sn de getirdi (DB nin serve edildiği Pc nin özellikleri ve network hızı gibi çeşitli etkenlere göre değişir). Aslında bu gibi yapılarda ilgili  StoraProcedure e paging parametreleri vererek daha performanslı ve hızlı bir sorgu yazabiliriz ancak bu durum için bile Cache yapısını uygulamamıza entegre edebiliriz. Şimdi bu raporları feed eden bir mobil uygulamamız, Web Sayfanız veya bir masaüstü uygulamanız olabilir ve iş ilgili uygulamanın kullanım oranına göre dakikada 100-200 request te bulunuyor olabilirsiniz. Bu uygulamalara db ile connection'ı sağlayan bir Web Api uygulamamız olsun. Şimdi yukarıda ki case de uygulamada bulunan RaporlarController 'ına dakikada 100-200 arası istek bulunmakta. Ne yapacağız peki sürekli olarak DB ye git select * from Raporlar deyip 200 bin kayıtı almak için 15 sn sürsün network vs işlemlerinden dolayı 2 sn de ordan olsun artı birde kullanıcının internet hızı kotalımı dersin :) ttnet sağolsun hızı düşürmüş 2 mb'e ve oda yaklaşık olarak 5 sn sürsün diyelim (değerler tamamiyle dummy dir). Şimdi küçük bir matematik işlemiyle ortalama kaç sn de veriyi getiriyoruz;

DB QueryResult : 15 sn

WebApi projesinin Download Süresi : 2 sn

Client uygulamasının Download Süresi : 5 sn

Client uygulamasının bu veriyi ekrana çizmeside yaklaşık 2 sn diyelim (Performanslı cihazlarda)

int[] arr = { 15 , 2, 5, 2 };
 
int sumResult = arr.Sum();
Console.WriteLine(sumResult); 
24 saniye 

Adama "Oh My God" dediğinde "Yes your god" diye cevap verirler. 

Tamı tamına 24 saniye  (biraz abartmışta olabiliriz ). Günde ortalama 100 kişinin kullandığını düşündüğümüzde her gelen 24 sn beklicek. Böyle bir projeyi al çöpe at derler adama. Benzer bir olay daha önce çalıştığım bir şirkette başıma geldi ve page_load da db ye gidip 4.600.000 kayıt için sorgu atılıyordu ve bazı işlemler yapılmaya çalışılıyordu. Projeyi bana assign edip müşteri sayfayı açamıyormuş bi bakarmısın dediler ve sorunu anladığımda yazılımdan soğmuştum diyebilirim. 

Her neyse gelelim konumuza. Projeyi bu halde bırakmayalım ama çöpede atmayalım. Projemize sağ tıklayıp nugetten WebApi OutPutCache.Core ve OutPutCache.v2 dll lerini ekleyelim.

Senaryomuz şu şekilde olacak;

1-Controller bazında hem server side için hemde client için iki tarafta da cache sağlayacak bir yapı yapıyoruz. Kullanacağımız kütüphaneye 2 parametre vericez  ServerTimeSpan  ve ClientTimeSpan .  Biri ServerSide için cache'i sağlicak yani kendine gelen ilk request'in response'ını alıp set edilen süre boyunca aynı requestle başka bir kullanıcı geldiğinde cache den alıp o yeni gelen kullanıcıya verecek. Diğeri ise ClientSide için clienta dönen response'un header'ına Cache-Control →max-age=60 eklicek. Bu şu anlama geliyor; Client'a diyor ki arkadaş ben bu respons'u 60 sn cache ledim ve sende istersen gelen response'u biyerde tutup bana 60 sn boyunca gelmeyebilirsin. 60  sn sonra tekrardan gel. Şimdi gelelim code tarafına ilk olarak WebApiCacheAttribute adında CacheOutputAttribute inherıt olan bir attribute tanımlıyoruz. Alında direkt olarak CacheOutputAttribute  controllerımızın içerisindeki metodların başına ekleyebilirdik ancak yönetimi daha kolay olur düşüncesiyle araya işimi daha kolaylaştıran WebApiCacheAttribute  adında CustomAttribute ünü yazdım.

public class WebApiCacheAttribute : CacheOutputAttribute
    {
        public ApiCacheAttribute()
            : this(WebConfigApiClientCacheDuration,WEebConfigApiServerCacheDuration){ }

          public ApiCacheAttribute(int clientCacheDuration = 0,
                                 int serverCacheDuration = 0)
        {
            base.ServerTimeSpan = serverCacheDuration;
            base.ClientTimeSpan = clientCacheDuration;
        }
    }

Üstte görüldüğü gibi bu Cache attribute'ü 2 parametre alıyor. Bu parametreleri attribute implementasyon sırasında aşağıda olduğu gibi biz değer atamaz isek WebConfig dosyasında tanımlı olan değerli alarak Cache sürelerini set ediyor.

WebConfig de appsettings de kayıtlı olan değerleri okuyarak cache işlemini yapar

[WebApiCacheAttribute]
public IHttpActionResult GetItems()
{
      var products= new IkiYuzBinKayit(); //db den 200 bin kayit getirmişiz varsayalım
      return Ok(product);
}

Ama istersek aşağıda olduğu gibi bizde bu değerleri set edebiliriz

[WebApiCacheAttribute(ApiServerCacheDuration=120,ClientCacheDuration=120)]
public IHttpActionResult GetItems()
{
     var products= new IkiYuzBinKayit(); //db den 200 bin kayit getirmişiz varsayalım
     return Ok(product);
}
 

Sonuç olarak web api projemizde cache attribute eklediğimiz metoda yapılan sorgular set edilen sürelere göre cache lenir ve o süre boyunca aynı parametrelerle gelen bütün kullanıcılara cachelenmiş olan response döner. Süreç server cache süresi bittiğinde sonlanır ve yeniden gelecek olan ilk sorgu beklenir ve döngü şeklinde devam eder.

 

Not ! Cache Cache'dir ancak hangi datanın cachelenip cachelenmemesi konusu çok ama çok önemlidir !! İyice düşünüp karar verilmesi gereken bir konudur.

Asp .Net Web Api Nedir

Daha önceki yazılarımızda Web Api dedik, Cache dedik, Exception Handling dedik ama Web Api nedir bir türlü bahsedemedik. Bu yazımızda kısaca Api & Asp.Net Web Api nedir konuşuyor olacağız.

Api Nedir ?

Asp .Net Web Api'a geçmeden önce Api nedir ondan bahsedelim. Aoi açılımı "Application Programming Interface" olan Türkçe'de uygulama geliştirme arayüzü anlamına gelir ve sahip olduğumuz service veya verileri dış dünyaya açıp başka uygulamaların-platformların kullanımına sunmak için belli kurallar çerçevesinde tanımlamalar yaptığımız arayüz dür. 

 

Asp .Net Web Api Nedir ?

Microsoft yetkilileri Web Api sunumlarından birinde şuna benzer bir şey söyledi "Biz daha iyisini yapana kadar en iyisi bu..!"

Asp .Net Web Api ise farklı türde sayısız client (browsers, mobile phones, tablets, pc, etc.) tarafından consume edilebilen HTTP protokolü üzerinden haberleşebilen servisler oluşturmak için kullanılan bir framework şeklinde tanımlayabiliriz. Asp .net MVC ile routing, controllers, action results, filter, model binders gibi ortak feature'lara sahip olduklarından bir takım benzerlikler göstermektedir ancak MVC Framework'ün bir parçası değildir. Asp .net Web Api Core Asp .Net'in bir parçasıdır ve MVC veya diğer web application türleri ile birlikte kullanılabilir. Aynı zamanda bütün bunlardan bağımsız stand-alone Web services application olarakta kullanılabilir. 

 

Neden Asp.Net We Api ?

Günümüz dünyasında teknolojini gelişmesiyle birlikte firmalar artık web tabanlı uygulamalar üzerinden müşterilerine tam olarak ulaşamaz hale geldiler. İnsanlar artık günlük hayatlarının nerdeyse %50 sini akıllı telefonlar, tablet pc vs ile geçiriyorlar ve bu cihazlarda insanların hayatlarını kolaylaştıracak olan milyonlarca uygulama mevcut. Bunların yanında birde İOT ile birlikte gelecek 5 yılda dünyada 30 milyara yakın internete bağlanabilen cihazlar olacağından bahsediliyor ve buda belki milyonlarca Api geliştirmesi demek.

Firmalar veya uygulama geliştiriciler müşterilere daha kolay ve hızlı bir şekilde ulaşmada kullanmak için servislerini ve sahip oldukları verilerin bir kısmını browserlar yada internete bağlanabilen bu akıllı cihazlar tarafından consume edilebilmeleri için Api'lar geliştirmeleri gerekmektedir. Çünkü Api'lar yapısı gereği bütün programlama dilleri tarafından ortak kabul görmüş medya tiplerini (XML-JOSN..etc.) response olarak alıp gerekli parse işlemlerinden sonra kolayca kullanabilir. 

 

Web Api sahip olduğunuz veri ve servisleri birçok farklı cihazda kullanıma sunmak için expose edebilmenizi sağlayan şahane bir framework ve dahası Web Api .Net Framework üzerinde RESTful servisler inşa etmenizi sağlayacak ideal bir open source platform. WCF Rest service'lerinin aksine Web Api HTTP protokolünün bütün özelliklerini kullanır (URIs, request/response headers, caching, versioning, çeşitli content format'ları) WCF Rest Service'lerinde yapıldığı gibi farklı cihazlar için extra config ayarları vs yapmamıza da gerek bulunmamaktadır. Request'i yapılırken dönmesi gereken response'un XML mi yoksa JSON formatında mı olacağına client'ın seçimine bırakılmıştır çünkü Web Api birden fazla medya formatında response dönebilmektedir.

 

Başlıca Web API Özellikleri

  • Http Get, Post, Put ve Delete metodlarıyla çalışabildiğinden CRUD işlemelrini destekler,
  • Response'larda HttpStatusCode ve Accept Header parametreleri bulunur,
  • Response'lar kullanıcının istediği türde MediaTypeFormatter tarafından formatlanabilir,
  • OData desteği bulunmaktadır ve Query yazması oldukça kolaydır,
  • Bir uygulama içerisinde veya IIS üzerinde host edilebilir,
  • MVC'nin bazı özelliklerini taşır (routing, controllers, action results, filter, model binders)

 

Neden Web Api'ı Seçmeliyiz ?

  • Bir web service'e ihtiyacınız varsa ve soap'a ihtiyacınız yoksa en iyi seçenek Web Api dir,
  • Geliştirme sürece WCF de olduğu kadar zahmetli ve sıkıntılı değildir,
  • Http tabanlı olduğundan Rest-ful servisler geliştirmek için en iyi seçenektir,
  • Exception ve Cache mimarileri oldukça performanslı ve yönetilebilir dir,
  • Open Source olduğundan sürekli olarak geliştirilip yeni feature'lar eklenmektedir,
  • Microsoft yetkilileri Web Api sunumlarından birinde şuna benzer bir şey söyledi "Biz daha iyisini yapana kadar en iyisi bu..!" bu demek oluyor ki tam destek.

yield nedir nasıl kullanılır

Bilineceği üzere bir class ın foreach iterasyonuna sahip olabilmesi için IEnumerable interfacesini implement etmesi gerekmekte. IEnumerable 'ı implemente eden class bu implementle birlikte override edilmesi gereken GetEnumerator metoduna sahip olur ve bu metodun içerisini doldurduktan sonra artik bu class da foreach ile gezebilecek duruma gelir. GetEnumerator metodunu override ederken, MoveNext(), Reset() metotlarini ve Current isimli propertyleri ile ilgili logic'i handle etmemiz gerekiyordu. İşte yield sayesinde bunları yapmaktan kurtuluyoruz. 

Mantigi oldukca basit ama bazi projelerde uygulamaya entegrasyonu sıkıntı çıkarabiliyor. Iste bu  sıkıntıları gidermek için C# 2.0 ile birlikte gelen yield keywordu sayesinde bu işlemlerin tumu bizim için arka planda yapilmis olacak.

Senaryomuz şu şekilde olsun; geriye db de kayıtlı olan ürünleri dönen bir metodumuz var ve bu metodu yield kullanmadan ve yield kullanarak yazmaya çalışalım.

Yield kullanmadan

     public static IEnumerable<Product> GetAllProducts()
            {
                using (var db = new DbEntity())
                {
                    var productList = from product in db.Product
                                      select product;
                    return productList.ToList();
                }
            }

 

Bu normal şartlarda kullandığımız yöntem. İlgile metodu aşağıdaki gibi çağırıp dönen listeye direk olarak erişebilirsiniz.

var productList = GetAllProducts();

yield kullanarak ise şu şekilde yazabiliriz 

Yield Kullanarak

public static IEnumerable<Product> GetAllProducts()
            {
                using (var db = new DbEntity())
                {
                    var productList = from product in db.Product
                                   select product;
                    foreach (var item in productList)
                    {
                        yield return product;
                    }
                }
            }

yield da ise şu şekilde çalışır;

döngüye her girdiğinde yield return product satırında fonksiyonun çağrıldığı yere ilgili product item'ını döner yani return'ü gördü diye foreach den ve metoddan direkt çıkmaz ve listenin içindeki tüm elemanlar bitinceye kadar bu işlemi yapmaya devam eder.

IL Disassambler(ILDASM) acarak code tarafında MoveNext,Reset ve Current gibi uyeler yazmamamiza ragmen yield keywordu sayesinde arka planda bunlarin yazildigini goruyoruz.

 Bir diğer örnek olarak ise şunu verebiliriz; 

public void Consumer()
{
    foreach(int i in Integers())
    {
        Console.WriteLine(i.ToString());
    }
}

public IEnumerable<int> Integers()
{
    yield return 1;
    yield return 2;
    yield return 4;
    yield return 8;
    yield return 16;
    yield return 45;
}

Foreach de dönerken her bir int i için IEnumerable<int> Integers() metoduna giderek değerleri bize teker teker döndürebiliyor.

INotifyPropertyChanged Nedir Nasıl Kullanılır

WPF, Windows10 (Mobile,Desktop etc.) uygulama geliştirme ile uğraşan arkadaşlar bilirler ki arayüz tarafında XAML (Extensible Application Markup Language) kullanılır ve codebehind'dan yani C# tarafından uygulama ekranında bulunan herhangi bir UI Control'ünün değeri değiştirme işlemlerini sık sık yaparız. İşte bu gibi işlemleri örneğin TextBlock'un Text'ini değiştirme işlemini C# tarafında tblName.Text="Caner"; yazmak yerine INotifyPropertyChanged interface'ini kullanarak bu gibi işlemleri kolaylıkla ve daha yönetilebilir bir şekilde yapabiliriz. (Tabi sadece TextBlock için geçerli değil, Button'un click event'i gibi durumlarda da INotifyPropertyChanged'İ kullanabiliriz)

INotifyPropertyChanged nedir dersek kısaca şöyle tanımlayabiliriz ;

"C# tarafında yani CodeBehind da tanımlı olan bir class'ın property'sinin değeri değiştiğinde bu değişimden UI'ı yani XAML tarafını bilgilendirmesi" demektir.

 

 

 

Şöyle bir örneğimiz olsun; bir adet Windows Phone uygulaması ve ekranda 2 tane TextBox, 1 tane Button ve 1 tane de Label olsun. Kullanıcı bu 2 TextBox'a birer sayı girecek ve Button'a tıkladığında hemen altında bulunan Label'da bu iki sayının toplamını yazacak.

 

 

HesaplaViewModel.cs class

MVVM pattern ile daha önce uğraşan arkadaşlar bilirler hiyerarşi Model, View, ViewModel diye ayrılır. Bizim uygulamamızda şuan Model yok ancak MainPage.xaml View'i ve hemen aşağıda bulunan ViewModel class'ımız var. Bu class View'imizin DataContext'i olacak ve UI tarafı ile bütün haberleşme bu class üzerinden gerçekleşecektir. ViewModel içerisinde tanımlı olan parametreleri UI'a DataContext üzerinden Binding işlemleri yapıp propertChanged anından UI thread'den durumu haberdar edip Bind olduğu UI Control' deki değerini update edecektir veya bir event ise o event'in davranışına göre çalışacaktır.  

  public class HesaplaViewModel : INotifyPropertyChanged
    {
        private ICommand _HesaplaCommand;
        private int _ilkSayi;
        private int _ikinciSayi;
        private int _sonuc;

        public HesaplaViewModel()
        {
            HesaplaCommand = new RelayCommand(Sum);
        }

        public int İlkSayi
        {
            get { return _ilkSayi; }
            set
            {
                _ilkSayi = value;
                OnPropertyChanged("İlkSayi");
            }
        }

        public int İkinciSayi
        {
            get { return _ikinciSayi; }
            set
            {
                _ikinciSayi = value;
                OnPropertyChanged("İkinciSayi");
            }
        }

        public int Sonuc
        {
            get { return _sonuc; }
            set
            {
                _sonuc = value;
                OnPropertyChanged("Sonuc");
            }
        }

        public ICommand HesaplaCommand
        {
            get { return _HesaplaCommand; }
            private set
            {
                _HesaplaCommand = value;
                OnPropertyChanged("HesaplaCommand");
            }
        }

        private void Sum(object obj)
        {
            Sonuc = İlkSayi + İkinciSayi;
        }

        public event PropertyChangedEventHandler PropertyChanged;
        protected virtual void OnPropertyChanged([CallerMemberName] string propertyName = null)
        {
            var handler = PropertyChanged;
            if (handler != null) handler(this, new PropertyChangedEventArgs(propertyName));
        }
    }

 

RelayCommand.cs class

RelayCommand button'a tıklandığında çalışacak olan event gibi düşünebiliriz, Butonun click statelerini aşağıda ki metodlar sayesinde handle edip yönetimini sağlıyoruz

    public class RelayCommand : ICommand
    {
        private Action<object> _action;
        public RelayCommand(Action<object> action)
        {
            _action = action;
        }
        public bool CanExecute(object parameter)
        {
            return true;
        }
        public event EventHandler CanExecuteChanged;
        public void Execute(object parameter)
        {
            _action(parameter);
        }
    }

 

App.xaml 

Burda HesaplaViewModel'ini Resource olarak tanımlama işlemini yapıyoruz.

<Application
    x:Class="App1.App"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:App1">
    <Application.Resources>
        <local:HesaplaViewModel x:Key="HesaplaViewModel" />
    </Application.Resources>
</Application>

 

MainPage.xaml View'ı

App.xaml de tanımlaış olduğumuz Resource'u DataContext = "{StaticResource HesaplaViewModel}" olarak View'imize verip Binding işlemlerini yapacağız.

<Page
    x:Class="App1.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:App1"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    Background="{ThemeResource ApplicationPageBackgroundThemeBrush}"
    DataContext="{StaticResource HesaplaViewModel}">

    <Grid>
        <Grid HorizontalAlignment="Center" VerticalAlignment="Center">
            <Grid.RowDefinitions>
                <RowDefinition Height="auto"/>
                <RowDefinition Height="auto"/>
                <RowDefinition Height="auto"/>
                <RowDefinition Height="auto"/>
            </Grid.RowDefinitions>
            <TextBox Grid.Row="0" Text="{Binding İlkSayi,Mode=TwoWay}" PlaceholderText="İlk Sayı" Width="200" HorizontalAlignment="Left"/>
            <TextBox Grid.Row="1" Text="{Binding İkinciSayi,Mode=TwoWay}" PlaceholderText="İkinci Sayı" Width="200" HorizontalAlignment="Left"/>
            <Button Grid.Row="2" Content="Hesapla" Width="200" Command="{Binding HesaplaCommand}" />
            <StackPanel Orientation="Horizontal" Grid.Row="3">
                <TextBlock Text="Sonuç : " FontSize="20"/>
                <TextBlock Text="{Binding Sonuc,Mode=TwoWay}" FontSize="20"/>
            </StackPanel>
        </Grid>
    </Grid>
</Page>

 

OnPropertyChanged() metoduna parametre olarak string bir değer almakta. Bu değer propertychanged anında hangi değerin değiştiğini anlamak için bir nevi ID ye benzer bir string değer veriyoruz ve ilgili property'nin değerinin update olma anında hangi property ise bu string parametrelere bakrak anlayabiliriz. Ama bu parametreyi vermek zorunda da değiliz eğer OnPropertyChanged() metodunu bu şekilde kullanırsak da otomatik olarak proeprty'nin ismini alacaktır.

 

Sonuç olarak ise hesapla butonuna tıklandığında çıktı şu şekilde olacaktır.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Görüldüğü üzre yazımızın başında bahsettiğimiz gibi code behind da tblName.Text="Caner";  gibi bir işlem yapmayıp bunu yerine INotifyPropertyChanged interface'inden faydalanıp işlemlerimizi öyle yaptık. Bu bize ne katar dersek, büyük çaplı projelerde genellikle MVVM pattern'i kullanılır ve INotifyPropertyChanged de bu pattern'in ayrılmaz bir parçasıdır. Bu şekilde yazdığımız kod hem daha "kaliteli"(tırnak içinde) hemde daha yönetilebilir oldu. Yarın bir gün dendi ki aynı işlevi yapan bir WPF app geliştirelim. Bu gibi bir durum için yazmış olduğumuz HesaplaViewModel'ini aynen olduğu gibi tek bir satır bile değiştirmeden referans olarak verilen ilgili proje içinde kullanabilir ve böylece çok büyük bir yazılım maliyetinden de kurtulmuş oluruz.

 

Dependency Injection

Yazılımla ilgilenen kişiler bilirler ki proje geliştirmede süreçler çok önemlidir. Müşteriye gidilir, ihtiyaç olan şey dinlenir, analiz edilir ve analiz yazılıp müşteriye sunulur. Müşteri analizi kabul eder ve development süreci başlar. Analiz developera gelir ve 3 ay sonra işini bitirdikten sonra müşteriye projenin sunumu yapılır ve müşterinin çenesi o anda açılır. Bunu da ekleyelim, şunu da yapalım, bu da olsa daha iyi olur.. süreli olarak bu gibi cümleler duymamak hiçten bile değildir. Bu gibi durumları göz önüne alarak projeyi olabildiğince esnek hazırlamak yararımıza olacaktır.

Proje içerisindeki modüllerin bir birlerine gevşek bağlı(loosely coupled) olması, üstte bahsettiğimiz gibi sonradan oluşabilecek talepler için minimum efor sarf change request leri yani sonradan istenilen değişiklikleri hayata geçirmemize katkıda bulunabilir. Bir senaryo ele alalım;

Person ve Car adında classrımız olsun ve bu classların içerisinde Drive adında bir metodumuz olsun ve kullanıcı classının instance alınıp Drive metodu çağrıldığında kullanıcı Car classının Drive metodu çağrılarak araba kullanıyor olsun.

public class Person {
  private Car myCar = new Car();
 
  public void Drive()
  {
     this.myCar.drive();
  }
}

 

Müşterinin isteğine göre araba sürebilen bir Person objesi yaratmış olduk. Peki ya müşteri 2 ay sonra "bu person kamyonda sürsün, motorsiklette sürsün.." derse ? İşte bu gibi durumlar için üstte yazdığımız class işimizi görmicektir ve müşterinin istediğini geliştirmemiz belkide bu güne kadar ki development süresi kadar zaman alabilir de (projenin büyüklüğü gibi vs. konulara bağlı). Üstteki sorunumuz Person objesi Car objesine bağlı ve bu nedenle Bus ve Motorcycle classlarını Person objesine entegre etmemize engel oluyor. İşte Dependency Injection burda devreye giriyor. Amacımız Person objesinin bağımlılığını en aza indirgemek. Bunun için ilk olarak IVehicle adında içerisinde Drive metodu bulunan bir interface yazıyoruz.

public interface IVehicle {
  void Drive();
}

Sonrasında ise bizim Car, Bus ve Motorcycle class larımız IVehicle implemente etsinler

public class Car : IVehicle 
{
  public void Drive()
  {
    Console.WriteLn("Araba sürülüyor");
  }
}

public class Bus : IVehicle 
{
  public void Drive()
  {
    Console.WriteLn("Otobüs sürülüyor");
  }
}

public class Motorcycle: IVehicle 
{
  public void Drive()
  {
    Console.WriteLn("Motorsiklet sürülüyor");
  }
}

Yukarıda ki geliştirmeler ile birlikte artık Person class'ımızın Car Bus gibi objelere olan bağlılığını ortadan kaldırmış olduk yani birbirlerine gevşek bağlı(loosely coupled) halede getirdik diyebiliriz.

Person classımızın yeni hali aşağıdaki gibi olacaktır.

public class Person {
  private IVehicle vehicle {get; set;}

  public Person(IVehicle Vehicle)
  {
    this.vehicle = Vehicle
  }
 
  public void Drive()
  {
     this.vehicle.Drive();
  }
}

 

Person classımızı kullanacağımız yerde artık şu şekilde yazabiliriz;

//Araba sürmesini istediğimizde
var person=new Person(new Car());
person.Drive();

//Otobüs sürmesini istediğimizde
var person=new Person(new Bus());
person.Drive();

Burada IVehicle interfaceîni implemente eden sayısız nesne ekleyebiliriz veya bu nesneler üzerinde değişiklik yapabiliriz ancak bu durum Person classını hiç ilgilendirmiyor çünkü herhangi bir nesneye bağlı değildir.