- N-Tier uygulamaların gelişimi
- Data-Centric N-Tier mimari
- Domain-Centric N-Tier mimari

N-Tier Uygulamalar

- N-Tier tanımlamak
- Logical - Physical Seperation
- Typical Tiers

Tier ve Layer Nedir?

LAyer, mantıksal ayrım olup Tier ise fiziksel ayrım için kullanılır.
Örneğin programınızı yazarken UI(Kullanıcı Arayüz) katmanı, BUSINESS(İŞ) katmanı ve DATA(Veri) katmanı olarak 3 dll geliştirdiğinizi ve tüm bunları ayrı projelerde kodladığınızı düşünün. Artık 3 Layers bir uygulamanız var demektir. Layerlarınızın her birini 3 farklı makinede/sistemde barındırırsanız N-Tier ile tanımlanacak N sizin için 3 olur. Yani 3-Layers olarak geliştirdiğiniz projenizi 3-Tiers sunuyor olursunuz. Bu layer'ların 3'ünü de tek bir bilgisayarda hizmete sunuyorsanız 1 Tier'ınız oldu demektir. Yani MVC uygulamanızda M, V ve C için 3 farklı proje(namespace, assembly, SOFTWARE DESIGN PATTERN'e göre vs.) geliştirdiniz ve bu layerlarınızı tek bir IIS sunucusunda(1-Tier) barındırdınız. Uygulamanızı en basit olacak şekilde windows form olarak geliştirdiniz(tek process ya da tek assembly) ve istemciye yükleyerek çalıştırdınız 1-Layer ve 1 Tier. Uygulamanızın parçaları eğer farklı process, makine, cihaz vs de çalışıyorsa bunlar fiziksel ayrımlar olacaktır ve sebebi bu kez SOFTWARE ARCHITECTURE.

Monolithic Application

Access ile yazılmış bir uygulama monolitik olacaktır. DB ve KOD içinde ve mantıksal ya da fiziksel bir ayrım yapılamayacaktır. Aynı şekilde konsol uygulamaları da monolitiktir. Eğer fiziksel olarak bölümlere ayırmış olsaydık yani data servislerini ayrı, uygulama servisini ayrı fiziksel katmanlara ayırsaydık; ölçeklendirme, güvenlik, hata toleransı ve yük dengesini dağıtmak gibi konularda faydalar üretebilirdik.

1. Önceleri tüm kodu tek bir assembly olarak yazar aynı makinedeki veritabanı sunucusuna bağlanarak iş yapardık.
2. Sonra uygulama içindeki katmanları keşfettik, UI, BLL(business logic layer), DAL(data access layer).
3. Sonra database sunucusunu ayrı bir makinede kurduk.
4. Sonra data ve iş katmanını ayırarak bir servis içinde tutarak ayrı bir makinede tutarak farklı uygulamaların(UI katanların) uygulama servislerini(BLL, DAL) kullanarak Data Servislerine(db tier'ına) erişmelerine imkan verdik.

N-Tier ile:

1. Tekrar kullanımları sağladık(mobil, masaüstü, browser vs. uygulama arayüzlerinin application services(BLL,DAL...) katmanlarını kullanarak arkalarındaki data services katmanlarına erişmesi gibi)
2. Takımların ayrımlarını ve bu sayede geliştirme verimliliğini yakaladık
3. Katmanlara bölünmüş(tier ve/veya layer) yapıların bakımı daha kolay oldu
4. Birbirine daha esnek bağlanan yapılara sağladık (loose coupling)

End Runs'dan kaçınmak

Eğer bir katmanınız sonraki katman yerine daha ötedeki katmanları çağırıyor ya da aşağıdaki katman çok yukarıdaki katmanlara veriyi aradaki katmanları atlayarak gönderiyorsa bu yapı sorunlu olacaktır.

Data-Centric N-Tier Dizayn

IEnumerable ve IEnumerator farkları nelerdir

IEnumerable interface'i bize hangi metodu yazmayı zorlar ona bir bakalım:

public interface IEnumerable
{
  IEnumerator GetEnumerator();
}

Peki bu metodu kim çağıracakki biz implemente edelim?
foreach(var eleman in kolleksiyon)
foreach Arka tarafta şunu yaratır:

var oteleyen = kolleksiyon.GetEnumerator();
while(oteleyen.MoveNext()) // true dönerse, eleman var demektir
{
  Console.WriteLine(oteleyen.Current); // eleman'ın ToString metodunu çağır ekrana yaz
}
oteleyen.Reset(); // kolleksiyonun içinde döndük sona geldik, başa dönmek için resetleyelim

Bu da güzeldi ancak biz sadece GetEnumerator metodunu anlayalım derken başımıza MoveNext(), Current ve Reset() çıktı!!!
Peki bize bu metotları sağlayan tip kimdir?

var oteleyen = kolleksiyon.GetEnuemerator(); // aslında şöyle de yazılabilir
IEnumerator oteleyen = kolleksiyon.GetEnuemerator(); 

Demekki tipimiz IEnumerator. Peki o zaman IEnumerator bize ne şartı koşuyor içine bakalım:

public interface IEnumerator
{
  object Current { get; } // Şimdi üstünde bulunduğum elemanı ver bakalım
  bool MoveNext();        // sonraki eleman mevcut mu?
  void Reset();           // en baştaki noktaya geri gidelim
}

Anlaşıldıki bizim forEach bir IEnumerator(numaralandırıcı) istiyor ve onun nimetleri olan metot ve özelliği kullanarak kolleksiyon içinde dönüyor duruyor.
Peki bu tipin generic olması bize ne kazandırır? O zaman generic IEnumerator tipine bakalım ve casting ile kaybettiğimiz performansı bakalım nasıl geri alıyoruz?

public interface IEnumerator : IDisposable, IEnumerator
{
  T Current { get; }  
  // Sadece Current için T tipini sağlıyor. 
  // Zaten Reset void döner, MoveNext ise bool geriye performans kaybı yaşatan Current kalıyor
  // Onuda T dönecek şekle getirirsek sorun giderilmiş olur.
}

Peki GetEnumerator() metodu bize IEnumerator dönüyordu. Onu da generic ile IEnumerator dönecek şekle getirmemiz gerekmez mi?

public interface IEnumerable : IEnumerable
{
  IEnumerator GetEnumerator();
}

Şimdi tip dönüşümlerinden kurtulduğumuza göre performans rahatlığıyla bu iki tipi kullanabiliriz.
Gelin kendimize bir örnek yazalım ve makalemizi sonlandıralım. Eğer anlaşılmayan yerler olursa lütfen yorumlarınızda sorun ;)

class Cem : IEnumerable, IEnumerator
{
    T[] arr = new T[0];
    int iCur = 0;

    int idx = -1;
    public T Current
    {
        get
        {
            return arr[idx];
        }
    }

    object IEnumerator.Current
    {
        get
        {
            throw new NotImplementedException();
        }
    }

    public void Add(T a) { 
      Array.Resize(ref arr, arr.Length + 1); // dizimizi bir arttıralım ki yeni elemanı ekleyebilelim
      arr[arr.Length-1] = a; // artık bir büyüdüğüne göre -1 ile sonuncu sıraya yeni elemanı yerleştirelim
    }

    public void Dispose() { }

    public IEnumerator GetEnumerator() { return this; }

    public bool MoveNext()
    {
        var next = idx + 1;
        var sonuc = (next < arr.Length);
        if (sonuc) idx = next;
        return sonuc;
    }

    public void Reset()
    {
        idx = -1;
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        throw new NotImplementedException();
    }
}
class Program
{
    static void Main(string[] args)
    {
        var c = new Cem();
        c.Add(22);
        c.Add(32);
        c.Add(42);
        c.Add(44);
        foreach (var a in c)
            Console.WriteLine(a);
    }
}

Üçüncü şirketlerle çalışmak için yol haritası

Şirketinizde bir yazılım ihtiyacı hasıl oldu. Tabiki bunu yazabilirsiniz ama kimse sizin bu işi yapabileceğinize inanmıyor ya da daha fazla size yazdırıp şirketin size olan bağımlılığını arttırmak istemiyor.
Çözüm: gidin ve dışarıdan alın olacaktır.

1. İhtiyacın a'dan z'ye analizini yapmalısınız. Sanki siz geliştirecekmiş gibi özenerek bir A4 sayfa koparın defterinizden ve 1, 2 diyerek madde madde yazın.
2. Sonra kabataslak bu ihtiyacı karşılayabilecek anahtar kelimelerin olduğu google aramalarını yapın ve şirketlerin listesini çıkarın.
3. Bu firmaları ellerindeki belgelendirmelere göre sıralayın. ISO, SPICE, CMMI vs.
4. Sonra fiyatları almak için her biriyle görüşün ve ihtiyaçlarınızı karşılayabilecek şirketleri listenizde kalacak şekilde sıralayın.
5. Yani Order by, [ihtiyaç karşılama oranı], [belgelelerin sayısı], fiyatı.
6. Her zaman açık kaynak kod olmasını talep edin ki yarı yolda kalma ihtimaliniz düşük olsun.
7. Eğer bir ihtiyacınız olacak ve yazmalarını talep edecekseniz başta rakamı belirleyin(adam/gün, ihtiyaç türleri(küçük, büyük, kocaman vs.).
8. SLA(service level agreement) ile arıza durumlarına ne kadar zamanda çözüm üretebileceklerini, arıza kayıtlarını nasıl açmanız gerektiğini ve zamanında çözülmeyen sorunlar için yükümlülükleri sözleşmeye eklemeyi unutmayın.
9. Sizi ilgilendiriyorsa (denetimlerden geçiyorsanız, kalite prosedürlerini varsa) kesinlikle Yazılımın Validasyon belgelendirmesini isteyin.
10. Kurulum süreçleri hep zahmetlidir. Şifre al, şifrele, eski şifre neydi gibi bir sürü kıvır zıvır işle uğraşırsınız. Bu yüzden kurulumun bir resmi tatil günü gece yarısı sistem mühendisiniz tarafından diski bozulmuş bir makineyi tekrar ayanlandıramadığı durumlar için yapılması gerektiğini düşünmelisiniz. Kurulumun tüm aşamalarını sizinle paylaşmalılar !
11. Bakım sözleşmesi saçmalığını artık kazan kazan sözleşmesine çevirmek gerekiyor. Bakımda neymiş yahu, diyerek her sene ödediğiniz para için size yeni sürümleri vermeliler, ekstra özellikler (x adam/gün geliştirme hediye gibi) bonusu istemelisiniz.

Ayrıca bu projeyi siz de yazabilirdiniz elbette ama bence şirketinize bu konuda ısrarcı olmayın çünkü dışarıdaki şirketler sizin gibi personellere sahip olmadıkları için maalesef ve dünyanın her yerinde pişman edeceklerdir şirketinizi :)