three tier

• multi tier sistemlerden en scalable kabul edileni.. microsoft'un n tier adini verdigi $ey..
  
  bir uygulamanin user interface / business logic / data access olmak uzere 3 farkli bagimsiz layer'dan olu$masini ongoren model.. her bir layer birden fazla component'tan olu$abilir..
• (bkz: two tier)
• developer icin cin i$kencesinden beter. zira two tier sistemlerde business ve data tier'in toplandigi kisim three tier'a cevrildiginde ortadaki business layer tamamen ici bo$ data tier cali$tirmaktan ba$ka i$e yaramayan iskelet bir katman halini alir.
  
  her ne kadar bu $ekilde three tier modeline uymu$ gorunse de aslinda data tier izolasyonu pratikte hic bir avantaj saglamadigi gibi farkli data source'lara adaptasyonda yine kodun ba$tan yazilmasina engel olmayacaktir..
  
  bir de "getproductlist" fonksiyonu yazmak icin 3 ayri projede 3 ayri kod yazmayi gerektiren (business layer'da "getproductlist", data layer'da "getproductlist" ve bir adet "select * from products" query'si veya stored procedure'u) bu sacma mimari esneklik yerine projeyi hantalla$tirmaktan da oteye gitmemektedir. (bkz: tecrubeyle sabit)
  
  ideal bir three tier tasariminda business layer'in data layer'dan ham gelen bilgiyi $ekillendirip user interface layer'a aktaracagi ongorulmu$tur. oysa ki yazilimi sadece okulda bir ders olarak gormu$ bu tasarim ahmaklarinin atladigi nokta cogu zaman data layer'dan gelen bilginin zaten herhangi bir $ekillendirmeye ihtiyac duymadigidir. ozellikle .net gibi bolca data abstraction mekanizmasina sahip sistemlerde business layer'daki fonksiyonunuz $u hali alabilmektedir ve cogu zaman almaktadir:
  
  public dataset getproductlist()
  {
  return data.getproductlist();
  }
  
  $imdi burada microsoft'un ongordugu ideal yakla$im bunu yapmak yerine data layer'dan ham gelen bilgi icin gerekli xml schema yapilarini well defined $ekilde kodlayip dataset'ten ham gelen bilgiyi user interface'in algilayacagi ortak kabul edilmi$ bir yapiya donu$turmek gerekecektir. bu bir suru yeni a$amanin sisteme ek i$gucu gereksinimi olarak girmesini gerektirir:
  
  - user interface'in kullanacagi xml data structure'larin nihai olacak $ekilde tasarlanmasi.
  
  - dataset <-> xml cift yonlu donu$umleri yapacak kodlarin yazilmasi. (bkz: xslt)
  
  bu iki a$ama cok ufak gibi gorunseler de beraberlerinde pek cok teknik problemleri getirmektedir. ozellikle schema geli$tirmek cok zahmetli can sikici bir i$tir. bunun yani sira ileride data yapilarina eklenti yapildiginda guncellenmesi gereken birimlerin sayisi da inanilmaz olcude artmakta ve hata yapma (hata ortaya cikma) olasiliklari son derece artmaktadir.
  
  bir tane getproductlist yazmak icin checklist'in three tier sistemlerde nasil buyudugune bir bakin:
  
  - business layer'da "products" logical grubu yoksa bir tane yaratilacak.
  - data layer'da "products" logical grubu yoksa bir tane yaratilacak.
  - data layer'da products logical grubu altina getproductlist fonksiyonu tanimlanacak.
  - business layer'da products logical grubu altina getproductlist fonksiyonu tanimlanacak.
  - mantiksal tasarimin fiziksel implementasyonu:
  - logical gruplar icin birer class yaratilacak hem business hem data icin.
  - bu class'lara ilgili method'lar eklenecek.
  - business layer'dan data layer'i cagiran ve gerekli data structure donu$umlerini yapan fonksiyon eklenecek.
  - data layer icin sql query veya stored procedure yazilacak.
  - data layer'a db'den product list'i select edip sonucu xml olarak donduren fonksiyon eklenecek.
  - tum katmanlara hata kontrolleri ve handling'i eklenecek.
  - oldu mu sana yeni evin?
  
  $imdi bir tane getproductlist fonksiyonunu eklemek adina bu a$amalarin gecilmesi gereken bu yapida developer'lari geli$tirmeye sevketmek ne kadar mumkun uzerinde du$unmek gerekir.
  
  ayrica business layer data layer'dan gelen bilgiyi donu$tureceginden db layout degi$imlerinde gelecek data da degi$eceginden her halukarda business layer'in da modifikasyonuna ihtiyac duyacaktir. dolayisiyla aslinda bir izolasyon falan da tamamen havada sanaldadir. (bkz: sanalda a$k)
  
  burada microsoft'un onbin dolar maa$li muhendislerinin atladigi nokta buyuk projelerde dahi component kullaniminin nadiren cok parcali oldugudur. cogunlukla atomic olan bu i$lemler three tier modele adaptasyonu gayet sacma gorunen ve hic bir i$e yaramayan haller almaktadirlar.
  
  her microsoft distributed application design guidelines kitabinda ornek olarak "diyelim ki bir bankadan para cekeceksiniz" ornegiyle ba$lanir. yani $u para cekme fonksiyonu olmasa microsoft dedigi hic bir $eyi destekleyemeyecek ben bugun bunu gordum.
  
  ozellikle asp.net / smart clients gibi mekanizmalarda yurutulen i$lemler tamamen atomik birbirinden kopuk ilerler. zaten component'larda "acquire late release early" gibi bir motto'yu benimsetmeye cali$an microsoft'un component'larin buyuk transaction'lari handle edecegini nereden cikarttigini da kestirmek mumkun degil. boyle fonksiyonlar arada cikabilse de bunlarin sayisi uctur be$tir ve katmanlamaya da zerre ihtiyac duymayan sistemlerdir.
  
  microsoft'un three tier ayrimda diger bir major gerekcesi distribute etmeyi kolayla$tirmaktir. her ne kadar component'lari farkli katmanlara bolmek farkli makinalarda cali$abilmelerini saglayabilse de performans artirmayacaklari kuvvetle muhtemeldir.
  
  zira hic bir three tier uygulamanin business veya data component'lari visual rendering gibi cpu hogging i$lem yapmaz ve kuvvetli hesap istemez. bir distributed uygulamanin en buyuk yuku data tier ustundedir ve bunu da clustering ile rahatca cozmek mumkundur. component seviyesinde horizontal parcalama ise (business ile data'yi ayirmak) performans kazanci degil tam tersine kaybi ya$ayacaktir. zira en du$uk maa$li microsoft cali$ani bile farkedebilir ki en hizli network bile ram'den milyonlarca kat yava$tir. ayrica point of failure'lari arttiran diger bir etkendir.
  
  parcalara bolme ancak paralel cali$abilecek mekanizmalarda i$e yarar tek yonlu ve tek i$i data tier'dan gelen cevabi beklemek olan bir component'in hangi makinada durdugu hic bir anlam ifade etmedigi gibi performansi tamamen olumsuz etkileyecektir.
  
  yani parcalamak istediginizde tum component seti barindiran bir makinadan iki tane koyarsaniz o zaman bir i$e yarar. ama kalkip "ben data component'lari ba$ka makinaya koyacagim" derseniz bu hic bir senaryoda kazanc getirmeyecek sacma sapan bir i$guzarlik ve performans kaybi husule getirecektir.
  
  buradan boyle ustunde istatistikler haricinde zerre du$unulmemi$ kazma bir mimariyi dayatan microsoft'u selamliyorum.. hangi developer pe$lerinden gidecek merak da ediyorum.
• architecture ile patternler ile kafayı bozmuş, akıldan, mantıktan, hatta ve hatta şuurdan kesilmiş developerların profesyonel yazılım geliştirmenin olmazsa olmazı kabul ettikleri boktur.hesapta bir layerda yapılan değişiklikler diğer layerları etkilemeyecek. burdan bunu savunan kardeşlerime sesleniyorum;
  
  örneğin nedir en sık değişen bir yazılım projesinde a dostlar. fieldlar değil midir. mal analistler, histerik müşteriler, ya da değişen ihtiyaçlar yüzünden habire field (attibute da diyeyim de bozulmayın) ekleyip çıkarmaz mıyız. e sen şimdi products tablosuna bir field ekleyince kaç class, kaç metodda değişiklik yaptın be allahın malı. bu nasıl kolaylıktır. nasıl diğerini etkilemiyor. data layerdaki insert artık 8 değil 9 parametre alıyor sen nasıl business layerdaki insert metodunu güncellemezsin demezler mi adama. e noldu şimdi. two tier yapsa idin bir class taki metodları günceleyecek idin. şimdi noldu iki class oldu. e sen buna facade layerını bokunu püsürünü de eklemişsindir, 8 tane class yapmışındır ufacık iş için şimdi profesyonel yazacam diye. yapaydın ya bir tane class her entity için de bir metodu güncelleyip kurtulaydın. istediğin kadar yardımcı class ekle gerek duyarsan ona bişey demem. ama aynı nesne için 8 tane class yazma be sığır. ha derdin performanssa dersen ki ben nasdaq tadında iş aldım bir sürü server' a dağıtacam anca çalışır. o zaman da derim ki böl classlarını farklı class library lere, dağıt hepsini ayrı makinalara, emin ol daha fazla performans elde edersin.
  
  hayır bütün kodları user interface layera yazan adamlar senden daha akıllı mantıklı oldu şimdi benim gözümde. yapmayın etmeyin. ama birbirini etkilemiyor değil mi bir architect olarak düşününce. noluyor? "hepsinin kendi ihtiyacı var o yüzden güncelleniyor. diğeri yüzünden değil. değil değil hayır değil." dediğinizi duyar gibiyim. şimdi yanınıza gelip okkalı bir tokadın tersiyle silkeleyip kendinize getirmek lazım sizi ama her birinize yetişemiyorum. kendi kendinize tokat atıp "benim aklım mantığım var. niye billur gibi olacak projeyi hiç düşünmeden seksenbeşe bölüyorum da karmaşıklaştırıyorum. mallık yapmamalıyım" demenizi tavsiye ederim. erkut abi tadında tesisler açtırmayın bana!
  
  oop yapacam diye hayatınızı kaydırmayın a canlar. oop de ilk öğrendiğiniz kuralda olduğu gibi herşey "gerektiği kadar" olmalı.
  
  muhtemelen bilirsiniz microsoft' un petshop diye 11 tane projeden^* oluşan bir örnek solution' ı vardır. hani konusu "gayet basit bir site nasıl çığrından çıkarılır" olan. development süresinden tutun, değişiklik yapmanızı gerektiren durumlara kadar o örneği beğeniyorsanız, daha basit, daha mantıklı yapılamaz diyorsanız size söyleyecek birşey bulamıyorum.
  
  canı gönülden (bkz: #2235285)
• (bkz: data access application block)
• bir projede hangi mimari ve methodolojinin kullanılacağı, projenin ihtiyaçları, öncelikleri, büyüklüğü, ölçeklenmesi vs. gibi zilyon tane parametre göz önüne alınarak belirlenir. şirket içinde farklı departmanlarda hatta farklı coğrafi bölgelerde bulunan, farklı bilgi ve sorumlulağa sahip çok geniş bir ekip tarafından geliştirilen büyük bir yazılım için tasarlanmış bir yapıyı, 3 kişinin geliştirdiği bir web sitesi için kullanmak en amiane tabiriyle "mallık" olacaktır. ancak bu methodolojiyi, büyüklüğü göz önünde bulundurmadan tüm yazılım pojeleri için olmazsa olmaz olarak göstermek daha da büyük bir mallıktır.
• (bkz: codesmith)
• client server mimarisinde arada 3. bir katman olarak application katmanı bulunur. güvenliği sağlar ve istemciye haklar tanır.