if (tumIbanlar.Count > 0)
Orijinal gönderi : Anıl Yetik
if (tumIbanlar.Count > 0)
Orijinal gönderi : Anıl Yetik
Orijinal gönderi : Pınar Kılınç
TarifePeriyotDondur() SıraNumarasının sıfır verildiği senaryoyu desteklemektedir. Yani bu alana giriş yapılmış ise filtreye eklemektedir.
Burada sıra numarası ile giderek üç kez VT sorgusu atmış oluyoruz.
Sıra numarası vermeden (üç periyod için tüm ) verileri bir seferde çekebiliriz sonra sonrasında tek satırlık LINQ sorgusu ile istediğimiz bilgiyi kullanabiliriz.
Tablo üzerinde, koyduğumuz “Uniuqe Constraint” içinde “nullable” bir alan var ise orta katmanda bu UC yi kullanarak oluşturan FETCH ‘i kullandığımızda, ilgili alan için “null” değeri içeren yapılan çağırımlarda, sonuç dönmeyecek ve kayıt bulunamayacaktır.
Aşağıda, ilgili alanın null (ilgili framework’te null==0 olarak kullanılmaktadır) geldiği durum kontrol edilmiş, bu durumda FETCH yapılarak değil, klasik bir sorgulama ile kayıtlar çekilmiştir.
Nullable objelerin null’ı kontrol edilmeden, içindeki bir alana veya metoda erişmeye çalışmak çalışma zamanında hataya yol açacaktır.
TonajDT global tanımlanmış. Null olma ihtimali var.
private DataTable tonajDT
{
get
{
object tonajDT = ViewState["TonajDataTable"];
if (tonajDT != null)
return (DataTable)tonajDT;
return null;
}
private TrfTarifeTonajTransferObjectList SecilenTonajBilgilerindenTOListOlustur()
{
TrfTarifeTonajTransferObjectList trfTonajTOList = new TrfTarifeTonajTransferObjectList();
foreach (DataRow dr in tonajDT.Rows)
{
DataTable’ın kullanıldığı yerde null olma durumunu yönetmemiz lazım.
Bir listenin, referans ettiğimiz elemanının o listede olduğundan emin olmamız, kontrol etmemiz gerekir. En yaygın yapılan hata, boş bir listenin ilk elemanını okumaya çalışmaktır.
Hatalı durum, liste boş gelirse, kod çatlar.
Doğrusu, listenin boş geldiği durum her zaman yönetilmelidir.
Datatable operasyonlarında, yapılan kayıtların etkin olabilmesi için AcceptChanges() metodunun çalıştırılması gerekir.
Bu konuya ait sistemde yapılan bir düzeltmenin görüntüsü aşağıdadır.
Veri tabanına gitmek çok kaynak tüketen bir işlemdir. O nedenle, veri tabanı çağrısı yaparken, kendimize sormamız gereken bazı sorular vardır.
1)) Bu çağırıyı yapmama gerek var mı? Bu bilgi elimde hali hazırda var mı?
2)) Çağırımı yapmam gereken asıl ihtiyacım olan yer burası mı? Yoksa bu çağırımı yaptıktan sonra bu bilgiyi kullanmadığım bir senaryo var mı?
3)) İhtiyacım olan kadar mı yoksa daha fazla mı bilgi çekiyorum.
İhtiyacımız olan veri tabanı çağrısını, döngü içinde değişmeyen bir bilgi ile yapıyorsak, bu çağırımın döngü dışında bir kez yapılması yeterlidir.
Aşağıdaki örnekte, şirket bilgisi ile döngü içinde veri tabanı çağırısı yapılmaktadır. Hâlbuki kurulan döngünün şirket bilgisi ile bir ilişkisi yoktur ve bu bilgiyi değiştirmemektedir.
Böyle bir durumda bu çağrıyı döngü girişine alıp, entity’mizi istediğimiz bilgi ile doldurduktan sonra, son içinde bu entity’yi kullanabiliriz.
Veri tabanında bir istekte bulunan bir kod yazdığımızda, çektiğimiz veriye gerçekten ihtiyaç duyup duymadığımızı sorgulamamız gerekmektedir. Bu konudaki yaygın yanlış kullanımlar şöyledir.
VT çağırımı yapmadan önce, eleyebileceğimiz senaryoları önce kontrol etmek, gereksiz çağırımlara engel olacaktır.
Bir if kontrolünün operatörleri arasında, hali hazırda değeri atanmış bir tane var ise, önce sadece onu içeren bir if yazarak, gereksiz VT sorgusu atmamış oluruz. Sarıya boyanmış kısmın değeri hâlihazırda belli, o nedenle önce onu kontrol edelim.
İlgii tablo, sadece eğer yük adedi sıfıdan büyük ise çalışan for blok içinde çalışıyor. Yük olmadığı durumlar için boşuna kaynak kullanıyoruz.
Olması gereken, döndü içinde ihtiyaç duyulan kaynakları, döngüye girdiği zaman çalışacak blok içinde tanımlamak. Yeni bir “if” yazıp, bu kaynağı orada çekiyoruz.
Bu örnekte, birden fazla tablo (haliyle tablolar arası “relation” ) içeren bir veri kümesi oluşturuyor. Bu kümeden sadece bir alana (Bookin Numara) ihtiyacımız var. Bu alanı çekmek için ORM nin bize sunduğu bir entity’e ait tüm alanları çeken ilgili Collection sinifini kullanılmış. Bu durumda içinden bir tanesini kullanmak üzere tüm alanları tablodan çekmiş bulunuyoruz.
Bunun yerine çalıştığımız framework’un bize sağladığı aynı “relation” ve “filtre” seçeneklerini kullanabileceğimiz, fakat istediğimiz alanı seçmemizi sağlayan altenatif yaklaşımı kullanmalıyız. Örneğimiz için, yukardaki sarı ile işaretlenmiş satırları aşağıdaki sarı satırlar ile değiştirebiliriz.
int, long, short, byte: Bunlar “Value Type” tiplerdir.
“Null” ile kontrol etmeye gerek yoktur. “Null” değeri alamazlar.
http://msdn.microsoft.com/en-us/library/3ewxz6et.aspx
LINQ “Dil ile bütünleşik sorgulama” anlamına gelmektedir.
LINQ .NET Framework 3.5 ile ortaya çıkmıştır. Objeler üzerinde T-SQL benzeri sorgulama yapılmasını sağlar fakat bu sorgulama da tamamen nesnel ifadeler kullanılır. Yani nesneler ile veri tabanları arasında köprü görevi üstlenir. SQL kodu yerine programımızda nesneler kullanarak veriye erişimi sağlar.
LINQ ya ait sınıf ve arabirimler System.Linq sınıfı altında bulunur.
Klasik Yaklaşım, Döngü kurma (bu örnekte ayrıca, oluşan stringin sonunda fazladan bir “,” karakteri var.)
Döngü kurarak string birleştirme
Alternatif
//LINQ İLE, string birleştirme **UYGUN**
string bookingNumaralari = String.Join(",", bkgBookingColl.Select(i => i.Numara).ToArray());
Eğer kaynağımız DataTable ise
string bookingNumaralari = String.Join(",", dt.AsEnumerable().Select(i => i.Field<string>("Numara")).ToArray());
Liste birleştirilirken (fark alırken) döngü kurmak yerine, framework’un sağladığı yapıları kullanalım.
Bir metottan birden fazla değer dönmek için, bu değerleri REF ile parametre listesine eklemek yerine,
Yeni bir “struct” yazıp, bunu dönüş değeri tipi olarak kullanabiliriz.
http://msdn.microsoft.com/en-us/library/0taef578.aspx
Mümkün olduğunca çalıştığımız framework’un sağladığı yapıları kullanmaya çalışmalıyız.
Hem çalıştığımız platformun sağladığı (.NET, JAVA) hem de özel olarak projede kullandığımız framework’ler buna dâhildir.
Özellikle “string” manipülasyonlar ve matematiksel işlemlerde, bu işin acaba framework’te yapılasının bir yolu var mıdır diye kısa bir araştırma yapmak faydalı olacaktır.
string.IsNullOrEmpty()
olması gereken
(.net framework>3.5)
Date karşılaştırmaları için string çevrimlerine gerek yoktur.
Çalıştığımız framework’un sağladığı metodları kullanmalıyız.