İfade ağaçları hakkında okuduğum en iyi açıklama Charlie Calvert'in bu makalesi .
Özetlersek;
Bir ifade ağaç temsil neyi değil, yapmak istediğim nasıl bunu yapmak istiyorum.
Aşağıdaki çok basit lambda ifadesini düşünün:
Func<int, int, int> function = (a, b) => a + b;
Bu ifade üç bölümden oluşmaktadır:
- Bir beyan:
Func<int, int, int> function
- Bir eşittir operatörü:
=
- Bir lambda ifadesi:
(a, b) => a + b;
Değişken function, iki sayının nasıl ekleneceğini bilen ham çalıştırılabilir koda işaret eder .
Temsilciler ve ifadeler arasındaki en önemli fark budur. Geçtiğiniz iki tamsayı ile ne yapacağını bilmeden function(a Func<int, int, int>) 'yı çağırırsınız . İki tane alır ve bir döndürür, kodunuzun bildiği en fazla budur.
Önceki bölümde, ham çalıştırılabilir koda işaret eden bir değişkeni nasıl bildireceğinizi gördünüz. İfade ağaçları çalıştırılabilir kod değildir , bir veri yapısı biçimidir.
Şimdi, delegelerin aksine, kodunuz olabilir bir ifade ağaç yapmak ne demek olduğunu biliyoruz.
LINQ, kodu ifade ağacı adı verilen bir veri yapısına çevirmek için basit bir sözdizimi sağlar. İlk adım, Linq.Expressionsad alanını tanıtmak için bir using ifadesi eklemektir :
using System.Linq.Expressions;
Şimdi bir ifade ağacı oluşturabiliriz:
Expression<Func<int, int, int>> expression = (a, b) => a + b;
Önceki örnekte gösterilen özdeş lambda ifadesi, türünde olduğu bildirilen bir ifade ağacına dönüştürülür Expression<T>. Tanımlayıcı çalıştırılabilir kod expression değildir ; ifade ağacı olarak adlandırılan bir veri yapısıdır.
Bu, bir temsilciyi çağırabileceğiniz gibi bir ifade ağacını çağıramayacağınız, ancak onu analiz edebileceğiniz anlamına gelir. Peki kodunuz değişkeni analiz ederek neyi anlayabilir expression?
var body = expression.Body;
var parameters = expression.Parameters;
var firstParam = parameters[0];
var secondParam = parameters[1].
Burada bir ifadeden alabileceğimiz çok fazla bilgi olduğunu görüyoruz.
Ama buna neden ihtiyacımız olsun?
Bir ifade ağacının çalıştırılabilir kodu temsil eden bir veri yapısı olduğunu öğrendiniz. Ancak şimdiye kadar, neden böyle bir dönüşümü yapmak isteyeceğimize dair temel soruyu yanıtlamadık. Bu yazının başında sorduğumuz soru bu ve şimdi cevaplama zamanı.
LINQ to SQL sorgusu, C # programınızın içinde yürütülmez. Bunun yerine, SQL'e çevrilir, bir kablo üzerinden gönderilir ve bir veritabanı sunucusunda yürütülür. Başka bir deyişle, aşağıdaki kod aslında programınızın içinde asla çalıştırılmaz:
var query = from c in db.Customers where c.City == "Nantes" select new { c.City, c.CompanyName };
Önce aşağıdaki SQL deyimine çevrilir ve ardından bir sunucuda çalıştırılır:
SELECT [t0].[City], [t0].[CompanyName] FROM [dbo].[Customers] AS [t0] WHERE [t0].[City] = @p0
Bir sorgu ifadesinde bulunan kod, başka bir işleme dizge olarak gönderilebilecek bir SQL sorgusuna çevrilmelidir. Bu durumda, bu işlem bir SQL sunucu veritabanı olur. İfade ağacı gibi bir veri yapısını SQL'e çevirmek, ham IL'yi veya çalıştırılabilir kodu SQL'e çevirmekten çok daha kolay olacaktır. Problemin zorluğunu biraz abartmak için, bir dizi sıfır ve birleri SQL'e çevirmeye çalıştığınızı hayal edin!
Sorgu ifadenizi SQL'e çevirme zamanı geldiğinde, sorgunuzu temsil eden ifade ağacı, önceki bölümde basit lambda ifade ağacımızı ayırdığımız gibi, parçalara ayrılır ve analiz edilir. Verilen, LINQ to SQL ifade ağacını ayrıştırmak için kullanılan algoritma, kullandığımızdan çok daha karmaşıktır, ancak prensip aynıdır. İfade ağacının bölümlerini analiz ettikten sonra, LINQ bunları gözden geçirir ve istenen verileri döndürecek bir SQL ifadesi yazmanın en iyi yoluna karar verir.
Sorgu ifadesi gibi bir kodu, başka bir işleme geçirilebilen ve orada çalıştırılabilen bir dizgeye dönüştürme görevini yapmak için ifade ağaçları oluşturulmuştur. Bu kadar basit. Burada büyük bir gizem yok, sallaması gereken sihirli bir değnek yok. Biri basitçe kodu alır, veriye dönüştürür ve daha sonra başka bir sürece aktarılabilecek bir dizgeye çevrilecek kurucu parçaları bulmak için verileri analiz eder.
Sorgu, derleyiciye böyle soyut bir veri yapısında kapsüllenmiş olarak geldiğinden, derleyici onu neredeyse istediği şekilde yorumlamakta özgürdür. Sorguyu belirli bir sırada veya belirli bir şekilde yürütmeye zorlanmaz. Bunun yerine, ifade ağacını analiz edebilir, ne yapmak istediğinizi keşfedebilir ve sonra nasıl yapılacağına karar verebilir. En azından teoride, mevcut ağ trafiği, veri tabanındaki yük, mevcut sonuç kümeleri vb. Gibi herhangi bir sayıda faktörü dikkate alma özgürlüğüne sahiptir. Pratikte LINQ to SQL tüm bu faktörleri dikkate almaz. , ancak teoride ne isterse hemen hemen yapmak ücretsizdir. Dahası, bu ifade ağacını, elle yazdığınız, onu analiz edebilecek ve LINQ'dan SQL'e çok farklı bir şeye çevirebilecek özel bir koda geçirebilirsiniz.
Bir kez daha, ifade ağaçlarının yapmak istediğimiz şeyi temsil etmemize (ifade etmemize) izin verdiğini görüyoruz . Ve ifadelerimizin nasıl kullanılacağına karar veren çevirmenler kullanıyoruz.