Model Kimin Umurunda ki!

model_1MVC, MVP, MVVM olsun hangi tasarım şablonu olsun fark etmez en önemli elemanlarından birisi olan MODEL ne yazık ki ne yeteri kadar önem veriliyor nede bir sorun olduğu zaman çıkartabileceği sıkıntılar akıllara geliyor. View, Controller yada Presenter’e verilen önemin Model’e verilmemesi bazen hiç hoş olmayan hatalara sebep oluyor. Bu hatalar bazen bir sunum esnasında, denemeler yaparken yada en kötüsü son kullanının kullanımı esnasında oluyor. Geliştirme esnasında oluşan hatalar doğal olarak karşılanır, çünkü halen geliştirme ve iyileştirme süreci olduğundan dolayı değişiklikler sıklıla yapılır ve hata çıkma oranı oldukça yüksek olur. Sunum ve gösterim zamanında ise hataların çıkması biraz can sıkıcı olur. Örnek vermek gerekirse projenin durumu hakkında bilgi almak isteyen proje yöneticiniz yada daha kötüsü patronunuza yaptığınız bir sunum esnasında açılmayan bir ekran yada çalışmayan bir buton o an için sizi soğuk kış günlerinde deniz kenarında güneşleniyormuş gibi ısıtabilir. Ama en kötüsü ve ne istenmeyeni artık proje bitip arkanıza yaslanıp son kullanıcılara gönderildiğinde çıkan hatalar oluyor. Bu hatalar bazen bir tatil gününüzü yarım bırakmanıza, bazen uykudan uyanmanıza en kötüsüde işinizden olmanıza sebep oluyor. Birde bunun düzenltme yapıp tekrar kullanıcıya sunma süreci var ki bundan ne kullanıcılar memnun olurlar nede firmalar. Çünkü bu firmaya olan güveni azaltıp sonrasında aynı ürünü kullanma düşüncesini azaltıyor.

Peki hataların nelere sebep olacağına bu kadar deyindikten sonra bu Model’in bu hatalara ne şekilde sebep olduğuna yada olabileceğine bir göz atalım isterseniz.

Öncelikli olarak benim anlatacaklarımın tamamı tecrübe ve kişisel fikirlerden oluşmaktadır. Bunlara katılma yada katılmama tamamen sizin insiyatifinize bağlıdır.
  1. Kullanılan bir modelin sistemin diğer kısımlarında tekrar tekrar kullanılması durumu.
    Bu büyük bir oranda size sorun çıkartacaktır. Çünkü modele eklediğiniz heryeni özellik diğer kısımlar da eklenecek ve kontrollerinizi heryer için tekrar tekrar gözden geçirmenize neden olacak.
  2. Bir işlem için kullandığınız bir modeli genişleterek başka modeller oluşturma.Aslında bu da bir önce ki model ile benzer sorunlar ortaya çıkartıyor ama biraz daha kişiselleştirme imkanı size sunuyor. Ama unutmamak lazım baz modelinize yapılan her düzenleme(ekleme yada çıkartma) diğer türetilmiş modellerinizi etkileyecek.
  3. Modelinizin içerisinde iş mantıkları kullanma.Aslında bu durum yazılımcılar için kısa yoldan çözüm bulma ve günü kurtarma için çok sık kullanılan birşey. Örnek vermek gerekirse modelinizin içerisinde bulunan bir Enum’um integer değerini yada string olarak yazılışını almak istediğiniz de property tanımlayıp get meteduna bunu yazıp geçiyoruz. Bu en masum ve en sade olanı. Birde modelin içine matematiksel işlemler ve iş mantıkları koyduğunuz düşünün. Ne kadar eğlenceli değil mi :) Bazen güzel sonuçlar yakalamanıza ve bir çok yerde kullandığınız zaman size kolaylık sağlıyor. Ama bu da uzun vade de yapılan işlemde hatalara neden olabiliyor.
  4. Model’in içerisinde gereksiz ve kullanılmayan değişkenleri silmemek.Bazen aceleden silmeyi unuttuğumuz değişkenleri diğer çalışma arkadaşlarımız kullanımda olduğunu düşünerek kullanılması durumunda dolaylı olarak sebep olduğumuz hatalar ortaya çıkabiliyor. Tabi burada modelden gelen verileri kontrol etmek gerektiğini hiç bir zaman unutmamak lazım :)
  5. Database Entity enum yada entity’nin kendisini model olarak kullanmak yada içerisinde kullanmak.
    Özellikle Entity içerisinde relationship kullandığınız durumlar serialize etme kısımlarında sorun çıkartıyorl Mesela bir kullanıcı tablonuza bağlı kullanıcı sayfaları olsun. Kullanıcı tablonuzu serialize ettiğiniz zaman dolaylı olarak diğer sayfalarda serialize edilecektir. Aslında hiç bir zaman Entity nesnelerinizi model kullanmamanız gerekiyor. Onlar veritaşıma işini BLL ile DB arasında yapması gerekiyor. Başka hiç bir katman arasında değil !
  6. dynamic tipleri kullanmak bazen güzel oluyor.
    Evet dynamic tipler bir çok bakımdan esneklik ve kolaylık sağlıyor. Ama birde şöyle düşünmek lazım. View kısmınıza geçtiğiniz bilginin tipi IList mi yoksa int mi olduğundan emin olamazsanız yada daha kötüsü böyle bir durum olabileceğinden haberiniz yoksa sonrasında nasıl bir durum ile karşılaşırsınız ? Kötü hemde çok kötü değil mi :) dynamic tipleri modellerinizden uzak tutup bizim şu eski ve köhne tipleri kullanmaya devam edin
  7. Kullandığınız Framework’a özel tipleri model içerisinde kullanmak
    Unutmayın ki katmanlı mimarinin asıl amacı katmanlar arasında ki bağlılıkları ve etkileşimi en aza indirmektir. Model’de bize bu kolaylığı sağlayan en büyük etken. Ama siz Asp.Net MVC’nin yada NHibernate’in tiplerini, türlerini model içerisinde kullanırsanız bunu nasıl sağlayacaksınız? Her katmana istemediğiniz referansları vermeniz gerekecek o durumda da katmanlı mimariden ne kadar söz edilebilir? Model içerisinde tür yada ayrım için enum kullanmanız gerekiyorsa bunu Model katmanı içerisinde yeni bir tip oluşturun diğer katmanlarda da bunların dönüşümlerini yapın.

Aslında mimarilere baktığınız zaman en önemsiz ve en basit katman olarak Model görünebilir ama unutmamak gerekir ki bütün verilerinizi taşıyan ve katmanlar arasında ki iletişiminizi sağlayan en değerli elemanınız Model. Ona gerekli önemi ve değeri mutlak gösterin.

Facebook Comments

Bir Cevap Yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir