Bilmek istediğin her şeye ulaş

Microsoft'un LinqToSql'den desteğini çekmesi, LinqToSql ile geliştirilen veya geliştirilecek projelerde şimdi veya ileriki zamanlarda ne gibi sıkıntılara yol açabilir?

Olay yanlış anlaşılıyor galiba, LINQ to SQL artık geliştirilmeyecek. Örnek vermek gerekirse; .NET MVC 3'ten sonra 4 çıktı, 5 çıktı. Bunlar gibi bir gelişime uğramayacak sadece. MSDN forumlarında daima destek bulunur. Bundan 10 yıl sonrasını tahmin etmek istersek zaten sizin LINQ to SQL'e ihtiyacınız kalmayabilir. Daha yeni şeyler çıkabilir. Sonuçta daima bir .NET Framework kütüphanesi var ortada. Ama Microsoft geliştiricilere şunu diyor: "eğer projeniz büyükse LINQ to SQL kullanmanızı önermiyoruz, onun yerine Entity Framework kullanın" diyorlar. LINQ to SQL ile arasında o kadar da fark yok sonuçta syntax olarak.
  • Paylaş
9

Unluckypod, teşekkür ederim. ben şahsen programlamayı öğrenme aşamasında olan birisiyim. bi sorum daha olacak. neden büyük projelerde linqtosql önermiyor microsoft. ne eksiği var bu anlamda.

Kadircebel, açıkçası tam olarak bilmiyorum ama tahmin edebiliyorum yaşadığım tecrübelerden dolayı. Mesela akbank wingscard projesini yaparken performans sorunlarını sıkça yaşamıştık. ara ara işlemciye çok fazla yük bindiği durumlar oluyordu, mesela ToList() fonksiyonunun işlemciye anlık yaptığı etkiyi gördük basitçe ve şok olduk biraz. işlemciyi anlık %90 lara kadar çıkartıyor. çekçeğiniz kayıt 5 tane de olsa yapıyor bunu anlık. ama bu kısmı tricklerle geçebiliyorsunuz. şimdi bu sefer şöyle birşey çıkabiliyor ortaya: ben ne kadar performans kaydı yaşarsam o kadar trick olayına gireceğim belki. bu özellikle sunucunun ram'ine etki edecek. sonra ram'i temizlemek zorunda kalabilirim belki. büyük projelerde bu tarz sorunlar olabiliyor. ama normal bir yazılımcının daima bu tarz büyük projeleri olacağına inanmıyorum. zaten entityframework ü linqtosql in optimize edilmiş hali gibi düşünebilirsin. birde şu tartışmayı incelemeni öneririm : stackoverflow.com/questions/252683/is-li...

Unluckypod, peki son soru: okuduğum kadarı ile ado.net doğru kullanılırsa linqtosql den ve ef den daha performanslı ve stabil çalışabilirmiş. Siz katılır mısınız buna?

Kadircebel, ado.net zaten en hızlı olanıdır. fakat bu hızlar milisaniye cinsindendir. zaten öğrenilme aşaması olarak ado.net te öğrenilmeli, ado.net te proje nasıl geliştirilmeli öğrenilmeli eğer bilmiyorsanız. ama eğer biliyorsanız belli bir düzeye geldiyseniz zaten ado.net ile yazacağınız ayrıntılı şeyleri zaten linqtosql in yaptığını anlayacaksınız. size tavsiyem linqtosql veya entityframework özellikle kullanacaksanız eğer .net framework teki interface leri internetten araştırmalısınız. interface ler zaten performanslari etkileyen yapılar. zaman kaybı yaşamak istenmiyorsa linqtosql ile başlansa projeye bence hiçbir problem olmaz. çünkü yapacağınız proje ne kadar büyük olabilir mesela şimdilik? inploid.com u ele alırsak mesala; bu sitede server-side olarak yapılan aşamalar basitçe; veri ekle, veri güncelle, veri sil gibi ana başlıklar. aynı anda sitey 50 bin kişi girdiğini varsayalım ve aynı anda 50 bin kişi çeşitli zaman aralıklarında veri ekleme-düzenleme yapsın. milisaniye olayı burda önem kazanıyor. şuan performans olayını sadece server-side olarak konuşuyoruz mesela, ama daha bunun front-end kısmı var. performans arttırıcı daha bir sürü trick yapılabilir. son olarak, siz istediğinizi kullanın her şekilde arka planda bir .net framework kütüphanesi var ve geri dönüş yine ona :) sadece ado.net te işlemleri yapmanız birazdaha zaman alır zaman önemli ise. diğerlerinde interface yapılarını kullanmanız sizin manuel olarak yapacağınız performans ayarlarından çok daha iyi olacaktır buda ayrı bir gerçek.

Unluckypod, çok güzel ve ayrıntılı açıkladınız gerçekten teşekkür ederim. interface ler hafif yapılar olduğu için List yerine IList gibi, o yüzden kullanın diye yabancı bir sitede okumuştum. dediğiniz gibi ef ve linqtosql ado.net e bağlanıyor yani zaten ado.net temelinde çalışıyorlar, benim demek istediğim mesela nesne yönetimi (garbage collection hususu düşünüldüğünde özellikle) veya connection pool meselesi(ki anlamadım pek bu mevzunun yönetimini, bi videoda adam değişik bişiler yapmıştı bu anlamda; kontroller falan:)) v.s... konularda yönetim hakkı doğuyor diye anladım ben, eğer ado.net i doğru kullanmaktan bahsedersek. Bi çok yabancı kaynakta sözü edilen rastladığım diğer şeyler şunlar; eğer bol orm li veritabanı tasarımı kullanmışsanız ef büyük projelerde ve karmaşık veritabanı sistemlerinde hiç tavsiye edilmiyor çünkü sınıf yaratıldığında peşinden bi sürü sınıf daha örnekleniyor relational olduğundan, linqtosl ise linq ten dolayı hızlı diye anlıyorum, genel kanı okuduğum kadarı ile linq to dataset kullanılması performans açısından. yani linq in verileri hızlı alması ve döndürebilmesi farkı yaratan etki sanıyorum, çünkü testler Iqueryable sınıfı en performanslı çıkmış bu anlamda. yani iyi bir başlangıç olsun ve öle devam etsin inancını taşıdığımdan hep linq to dataset kullanmayı düşünüyorum.küçük proje ise tabiki ef veya linqtosql ideal bence. yukarıda yazdıklarımda yanlışlar olabilir dediğim gibi öğrenme aşamasındayım o yüzden kusura bakmayın. ayrıntılı cvp için tekrar teşekkürler sonra başınızı tekrar ağrıtırım çünkü bu yazılım işi gerçekten çok zor özellikle tam bişiler öğrendim tamamdır dediğimde karşınıza 100 kapı daha çıkıyor sonra her kapıda tekrar bi yüz tane daha, allam bitmicek bu ızdırap diyorum ben şahsen:)

Kadircebel, :) önemli değil. yardımcı olduysam ne mutlu bana. ya aslında zor değil gerçekten. bence yazılımı herkes yapabilir. sadece pratik bol yapmak lazım. garbage collector konusu application pool daki connection bağlantılarını temizlemekte kullandım ben bu zamana kadar. hani server'in rami temizlemeye yetişememesi lazım. önceleri ado.net yani klasik .net yazarken kullanmıştım ama linqtosql veya entity frameworkte gerekmiyor açıkçası. kullanırsanız cpu ya sadece ek yük. bunu denemiştim ve stress testinde garbage collector dan dolayı kalmıştı web yazılımı. ve microsoft ile bu olayı görüştüğümüzde microsoft taki teknik insanlar bile garbage collector un kullanılmasının çok sakıncalı olduğunu dile getirdiler. arkada zaten otomatik bir garbage collector deniyor zaten daima windowsta. kabaca siz çalışan gabage collector un üzerine birdaha garbage collector çalıştırdığınızda durum felç olabiliyor. ki zaten oluyor. garbage collector u benim bu zamana kullanmamın tek sebebi application pool larda meydana gelen connection yapılarını temizlemekti. ama son çıkan .net frameworklerde gerekmiyor gerçekten. bu arada aklınızın bir köşesinde bulunsun; yazılımda birşey güzel başladığında illa ki hep öyle devam edemez malesef :) illaki yeni bir teknoloji çıkacak veya zamanı gelicek illa ki geriye dönüp yazdığınız kodlara bakacaksınız ve optimize etme ihtiyacı duyacaksınızdır eminim. biraz fazla olacak belki ama yazılım konusunu ben tıp gibi kabul ediyorum bazen. çünkü kendinizi sürekli geliştirmelisiniz. önemli değil tekrardan :)

Unluckypod, bi önceki yorumunuzda işlemci ye yük bindiren tolist() olayı, veritabanındaki herhangi bir sınıfın çekilip tolist e casting olayı mı? sallıyorum mesela musteriler tablomuz olsun. return db.musteriler.ToList(); ...eğer öyleyse nasıl bir trick yaptınız ben de öğreniyim:)

Kadircebel, şimdi mesela .net mvc kullanıyorsanız. View kısmında tüm tabloya ihtiyacınız varsa kullanacaksınız tabi onda problem yok sadece bu sefer cpu ya yük bindirmemek için sesli olarak düşünürsem, aklıma ilk gelen en basidinden veriyi cach lemek olacaktır. hani tabloda veriler sürekli değişmiyorsa eğer cach işlemi mantıklı olacaktır. cach yerine viewmodel yapısı kullanılabilir. şuan aklıma gelmeyen bir sürü alternatif seçenek mevcuttur yani.

Unluckypod, anladım saolasın:)

Sonraki Soru
HESAP OLUŞTUR

İstatistikler

196 Görüntülenme3 Takipçi1 Yanıt