Şimdi Ara

Framework ve MVC nedir? Neden Kullanılır?

Daha Fazla
Bu Konudaki Kullanıcılar: Daha Az
1 Misafir - 1 Masaüstü
5 sn
19
Cevap
0
Favori
3.583
Tıklama
Daha Fazla
İstatistik
  • Konu İstatistikleri Yükleniyor
0 oy
Öne Çıkar
Sayfa: 1
Giriş
Mesaj
  • Türkiye'de henüz tam anlamıyla yaygınlaşmasada, framework yapıları her geçen gün popülaritesini arttırıyor. Framework yazılımın iskeletini oluşturan, sınıfları ve fonksiyonları içinde barındıran, geniş çaplı bir kütüphanedir. Yazılım geliştiriciler framework'ün sunduğu kütüphaneyi kullanarak daha kısa zamanda daha fazla iş üretebiliyor, daha düzenli bir yapı ortaya çıkarabiliyor ve dolayısı ile ileriye dönük çok daha kolay geliştirilebilir uygulamalar hazırlayabiliyorlar.


    Framework yapısını anlayabilmek ve etkin bir şekilde kullanabilmek için daha önce nesne tabanlı yazılım geliştirmiş olmanız gerekiyor. Eğer php dilini yeni öğrenmeye başlamışsanız ve nesneye dayalı programlamayı tam olarak kavrayamadıysanız framework dökümanları size karışık gelebilir.


    Kısa önbilgilerden sonra biraz teknik detaylara inelim ve framework dünyasını tanımaya başlayalım. Framework'ler ile gelen en güzel avatajlardan biri MVC (Model View Controller) yapısına sahip olmalarıdır.


    Model : Veritabanına kayıt girilmesi, kaydın güncellenmesi, kaydın getirilmesi vb. işlemleri yaptığımız kısımdır. (Kısaca insert, update, delete ve select işlemlerimizi yaparız.)

    Controller : View ile model arasında köprü görevi görür. View'den gelen verileri model'e gönderir ve işler. Aynı zaman da model'in işlediği verileri de view e aktarır.

    View : Uygulamanın ziyaretçilere göründüğü kısımdır. Html, Css, JavaScript vb. bu kısımda bulunur.


    Bu yapı sayesinde kodlarımızı katmanlara ayırırız ve çok daha derli toplu bir proje yapımız olur. Farklı yazılımcılar standartlaşmış kod yapısı sayesinde projeyi çok daha kolay geliştirebilirler.


    Mvc yapısı arayüz kodlaması yapan arkadaşlara da fayda sağlar. Php dosyasına tasarımı giydirirken kendisinin işine yaramayacak sql sorguları vb. diğer kodlarla uğraşmaz. Sadece echo ile ekrana basılan verileri ve döngüleri görür.


    Forumlarda ve bloglarda takip ettiğim kadarıyla framework kullanmayanların "Ben kendi kütüphane mi yazarım işime bakarım. Niye başkalarının yazdığı kodları kullanıp hazırcılık yapayım!" diye mesajlarına sıkça rastlamaya başladım. Eğer freelance çalışıyorsanız ve kodlamayı sadece kendiniz yapıyorsanız framework kullanmanıza gerek olmadığını söyleyebilirim. Bu durumda kendi kütüphanelerinizi oluşturup kullanabilirsiniz. Ancak yazdığınız kodları sizden başka yazılımcıların da geliştirmesi gerekiyorsa ve bir şirkette yazılımcı olarak çalışıyorsanız framework kullanmanızın kaçınılmaz olacağını düşünüyorum. Çünkü sizden sonra işe başlayacak kişinin oturupta sizin kendi yazdığınız yapıyı çözmesi ve geliştirmeye başlaması ciddi bir zaman ve iş kaybı yaşatıyor. Bir framework kullanılsaydı işe kullanılan framework'ü bilen bir eleman alınırdı ve projeler aksamadan devam ederdi. Aynı durum sizin yeni bir işe başladığınızda da geçerli. Özellikle bu konuda şirket tecrübesi olan arkadaşlar başkalarının kodlarını inceleyip, çözmeye çalışmanın ne kadar sıkıntılı ve sinir bozucu bir iş olduğunu tecrübe etmişlerdir.


    Zend, Codeigniter, CakePhp, Symfony şuan Türkiye'de kullanılan en popüler uygulama çatıları olarak göze batıyor. Eğer php alanınında kariyer yapmak istiyorsanız, en az 1 framework kullanarak proje geliştiriyor olabilmeniz size avantaj sağlayacaktır.


    Yazan : İbrahim HIZLIOĞLU

    Alıntıdır.







  • e ticaret işi yapacaksanız neden herşeyi tanımlayasınız ki , bir sürü framework var , size en cok hitap edeni kullanabilirsiniz. oturup 0 dan database tabloları servisler , fonksiyonlar , 1 sene kaybettirir size. her alanda bu böyle.
  • quote:

    Orijinalden alıntı: Kaygerya

    e ticaret işi yapacaksanız neden herşeyi tanımlayasınız ki , bir sürü framework var , size en cok hitap edeni kullanabilirsiniz. oturup 0 dan database tabloları servisler , fonksiyonlar , 1 sene kaybettirir size. her alanda bu böyle.

    1 sene mi. Senin bu dediklerini adam akıllı bir projeye dökmek yaklaşık 1.5-2 hafta diye bilirim sana. Entity Framework denilen bir nimet var. Bilmediğiniz konular hakkında araştırıp yorum yapmanızı öneririm. Framework başlı başına bir nimet olsa da MVC de günümüzde ki en büyük yenilik getiren platform. Önceden bu yok muydu ? Tabi ki de vardı. Design Pattern mantığıyla çalışıldığında zaten tam anlamıyla MVC mantığıyla çalışmış oluyorsunuz. Dediğim gibi. Dediklerini hiç zor şeyler değil. Her zaman derim , yazılımcı için tasarım bölümü en uzun süren bölümdür. Geri kalan bölüm ise zevk işidir ve 2-3 güne yapılır biter gider :)




  • quote:

    Orijinalden alıntı: zjnan

    quote:

    Orijinalden alıntı: Kaygerya

    e ticaret işi yapacaksanız neden herşeyi tanımlayasınız ki , bir sürü framework var , size en cok hitap edeni kullanabilirsiniz. oturup 0 dan database tabloları servisler , fonksiyonlar , 1 sene kaybettirir size. her alanda bu böyle.

    1 sene mi. Senin bu dediklerini adam akıllı bir projeye dökmek yaklaşık 1.5-2 hafta diye bilirim sana. Entity Framework denilen bir nimet var. Bilmediğiniz konular hakkında araştırıp yorum yapmanızı öneririm. Framework başlı başına bir nimet olsa da MVC de günümüzde ki en büyük yenilik getiren platform. Önceden bu yok muydu ? Tabi ki de vardı. Design Pattern mantığıyla çalışıldığında zaten tam anlamıyla MVC mantığıyla çalışmış oluyorsunuz. Dediğim gibi. Dediklerini hiç zor şeyler değil. Her zaman derim , yazılımcı için tasarım bölümü en uzun süren bölümdür. Geri kalan bölüm ise zevk işidir ve 2-3 güne yapılır biter gider :)

    Bence siz bilmediginiz konularda konusmayin. Basit opensource eticaret frameworku olan nopcommerceyi bir indirin inceleyin. Mvc icin uygun olan bu frameworke bir bakin kac ayda yazabilirsiniz bir dusunun. Bu framework uzerine birde admin panelleri userinterface raporlama vs koydugunuzda min 3 senede adam gibi eticaret sitesi yaparsiniz. Ufak tefek satislar icin elbet boyle bir ise kalkisilmaz. Daha basit bir yontemle halledile ilir. Ama projeyi indirip incelediginizde profesyonel bir eticaret altyapisinin nasil olmasi gerektigi konusunda da fikir sahibi olursunuz.

    Bu arada hurriyet holdingde bilgisayar muhendisi olarak calisiyorum. aynı zamanda sadece yazılım bilgim ile , yurtdışında 2 şirkete hissedar , 2 tane de şirketin yöneticisiyim. Yazılım ve yazılım işletmesi konusunda yeterli bilgi sahibiyim. . Bu surecleri uydurmuyorum. Ancak kabataslak hesapla buluyorum. Oturup hesaplasam buna yakin cikar. ancak hayatınızda profesyonel framework , profesyonel - kurumsal site görmediyseniz Affiliate nedir , pazarlama G/p nedit C/p nedir , satıs maliye toranları , tedarik zinciri, ürün teslimat takibi , çağrı merkezi takip sistemleri vs , bunları bilmiyor iseniz , boyle bir iş için 1-2 haftada biter demekte haklısınız. ayrıca insanların bilgi seviyeleri veyahutta konumları hakkında bilgi sahibi olmasan "Entity Framework denilen bir nimet var. Bilmediğiniz konular hakkında araştırıp yorum yapmanızı öneririm." gibi cümleler kurmayınız. bu cümlelerden entity frameworku yeni oğrendiğiniz ve teknoloji karşısında oldukça şaşırdığınız ayen beyan ortaya çıkmış. aşağılamak için söylemiyorum. elbette kendinizi geliştirin , projelerinizi kısa sürede yapın. öğrenin bunları.

    Neyse tekrar edeyim. Frameworkler yazilim maliyetlerini Ve surelerini dusururler, uygulama alani icin 0 dan baslamak yerine zaten pek cok hazir servis ve nesne kullaniminiz icin hazir iken oturup bunu bastan yazmak gereksizdir. Ayrıca oturup düşünüp kurgulamak da gereksizdir. zaten kurgulanmışlardır. Elbette lambda expressionsa linq entityframework zaten yazilimi hizlandirsa da uygulamanin hitap ettigi sektore ozel frameworklerin kullanilmasi sizi bazi sikintilar ve karsilasabileceginiz problemlerden de korur.



    < Bu mesaj bu kişi tarafından değiştirildi Kaygerya -- 11 Şubat 2013; 12:10:06 >
    < Bu ileti mobil sürüm kullanılarak atıldı >




  • KAVGA ETMEYİN :)
  • quote:

    Orijinalden alıntı: Kod_Dünyası

    KAVGA ETMEYİN :)

    zaten şu sayfadaki
    http://forum.donanimhaber.com/m_70873467/tm.htm
    yorumunu okuduktan sonra kavgayı bırak kaale almam :)
  • Yapay Zeka’dan İlgili Konular
    Daha Fazla Göster
  • quote:

    Orijinalden alıntı: Kaygerya

    quote:

    Orijinalden alıntı: Kod_Dünyası

    KAVGA ETMEYİN :)

    zaten şu sayfadaki
    http://forum.donanimhaber.com/m_70873467/tm.htm
    yorumunu okuduktan sonra kavgayı bırak kaale almam :)

    Siz kaale almayın yine de ama,
    Bende E-Ticaret sitesi yapıyorum ama ne 3 sene mi alıyor ne yığınlarca zamanımı. Fakat ben sizi anlıyorum ne demek istediğinizi. Önce kurumla oturulur konuşulur. 3 ay 4 ay proje hakkında toplantılar yapılır artık en son aşama platform da çalışma olayıdır. Ben de diyorum ki o kod yazma bölümü artık 1 aylık bir olaydır. Konuşup planladığınızı kağıda dökeceksiniz. Bundan da basiti olmaması gerek heralde bir yazılımcı için.
    Entity Framework'ü yeni tanıştığım falandan değil sadece ondan bahsetmek istedim. Siz Framework kurmucaksınız Framework ile çalışıcaksanız. Siz kendi framework'ünüzü yapma olayını bahsediyor iseniz , evet daha uzun süreçler bizi bekler. Dediğiniz gibi framework'ün hazır olanları kullanmak yeterlidir. Özel bir durumda da bence çokta sıkıntı yaratacağını düşünmüyorum.

    Ayrıca verdiğiniz linkteki yorumum da ne gördünüz ki kaale almayacaksınız ?




  • quote:

    Orijinalden alıntı: zjnan

    quote:

    Orijinalden alıntı: Kaygerya

    quote:

    Orijinalden alıntı: Kod_Dünyası

    KAVGA ETMEYİN :)

    zaten şu sayfadaki
    http://forum.donanimhaber.com/m_70873467/tm.htm
    yorumunu okuduktan sonra kavgayı bırak kaale almam :)

    Siz kaale almayın yine de ama,
    Bende E-Ticaret sitesi yapıyorum ama ne 3 sene mi alıyor ne yığınlarca zamanımı. Fakat ben sizi anlıyorum ne demek istediğinizi. Önce kurumla oturulur konuşulur. 3 ay 4 ay proje hakkında toplantılar yapılır artık en son aşama platform da çalışma olayıdır. Ben de diyorum ki o kod yazma bölümü artık 1 aylık bir olaydır. Konuşup planladığınızı kağıda dökeceksiniz. Bundan da basiti olmaması gerek heralde bir yazılımcı için.
    Entity Framework'ü yeni tanıştığım falandan değil sadece ondan bahsetmek istedim. Siz Framework kurmucaksınız Framework ile çalışıcaksanız. Siz kendi framework'ünüzü yapma olayını bahsediyor iseniz , evet daha uzun süreçler bizi bekler. Dediğiniz gibi framework'ün hazır olanları kullanmak yeterlidir. Özel bir durumda da bence çokta sıkıntı yaratacağını düşünmüyorum.

    Ayrıca verdiğiniz linkteki yorumum da ne gördünüz ki kaale almayacaksınız ?

    programın exesi 4 mb mış.




  • quote:

    Orijinalden alıntı: Kaygerya

    quote:

    Orijinalden alıntı: zjnan

    quote:

    Orijinalden alıntı: Kaygerya

    quote:

    Orijinalden alıntı: Kod_Dünyası

    KAVGA ETMEYİN :)

    zaten şu sayfadaki
    http://forum.donanimhaber.com/m_70873467/tm.htm
    yorumunu okuduktan sonra kavgayı bırak kaale almam :)

    Siz kaale almayın yine de ama,
    Bende E-Ticaret sitesi yapıyorum ama ne 3 sene mi alıyor ne yığınlarca zamanımı. Fakat ben sizi anlıyorum ne demek istediğinizi. Önce kurumla oturulur konuşulur. 3 ay 4 ay proje hakkında toplantılar yapılır artık en son aşama platform da çalışma olayıdır. Ben de diyorum ki o kod yazma bölümü artık 1 aylık bir olaydır. Konuşup planladığınızı kağıda dökeceksiniz. Bundan da basiti olmaması gerek heralde bir yazılımcı için.
    Entity Framework'ü yeni tanıştığım falandan değil sadece ondan bahsetmek istedim. Siz Framework kurmucaksınız Framework ile çalışıcaksanız. Siz kendi framework'ünüzü yapma olayını bahsediyor iseniz , evet daha uzun süreçler bizi bekler. Dediğiniz gibi framework'ün hazır olanları kullanmak yeterlidir. Özel bir durumda da bence çokta sıkıntı yaratacağını düşünmüyorum.

    Ayrıca verdiğiniz linkteki yorumum da ne gördünüz ki kaale almayacaksınız ?

    programın exesi 4 mb mış.

    Eğer o linke giderseniz yaptığım yorum da ne demek istediğimi anlarsınız. Orada ki espiriyi gerisini okusaydınız eminim ki anlardınız.




  • quote:

    Orijinalden alıntı: zjnan

    quote:

    Orijinalden alıntı: Kaygerya

    quote:

    Orijinalden alıntı: zjnan

    quote:

    Orijinalden alıntı: Kaygerya

    quote:

    Orijinalden alıntı: Kod_Dünyası

    KAVGA ETMEYİN :)

    zaten şu sayfadaki
    http://forum.donanimhaber.com/m_70873467/tm.htm
    yorumunu okuduktan sonra kavgayı bırak kaale almam :)

    Siz kaale almayın yine de ama,
    Bende E-Ticaret sitesi yapıyorum ama ne 3 sene mi alıyor ne yığınlarca zamanımı. Fakat ben sizi anlıyorum ne demek istediğinizi. Önce kurumla oturulur konuşulur. 3 ay 4 ay proje hakkında toplantılar yapılır artık en son aşama platform da çalışma olayıdır. Ben de diyorum ki o kod yazma bölümü artık 1 aylık bir olaydır. Konuşup planladığınızı kağıda dökeceksiniz. Bundan da basiti olmaması gerek heralde bir yazılımcı için.
    Entity Framework'ü yeni tanıştığım falandan değil sadece ondan bahsetmek istedim. Siz Framework kurmucaksınız Framework ile çalışıcaksanız. Siz kendi framework'ünüzü yapma olayını bahsediyor iseniz , evet daha uzun süreçler bizi bekler. Dediğiniz gibi framework'ün hazır olanları kullanmak yeterlidir. Özel bir durumda da bence çokta sıkıntı yaratacağını düşünmüyorum.

    Ayrıca verdiğiniz linkteki yorumum da ne gördünüz ki kaale almayacaksınız ?

    programın exesi 4 mb mış.

    Eğer o linke giderseniz yaptığım yorum da ne demek istediğimi anlarsınız. Orada ki espiriyi gerisini okusaydınız eminim ki anlardınız.

    arkadaşım , yanlış anlama. anladıgım kadarıyla teknolojiyi takip eden , yenilikler ile ilgilenen bir üniversite öğrencisinsin. sen hangi yolda isen , bizde geçtik o yollardan. değişik konularda insanlara yardı metme çabanı da gördüm. hatta soylediklerimin sert olmasına rağmen efendice cevap vermişsin , saygı duydum. ancak senin içinde oldugun kısmı geçtim , kendi tecrübelerimi edindim , ve bir noktaya geldim. sadece tanımadıgınız insanların bilgi-tecrübesi hakkında yorum yapmayın, yanılırsınız. birde dediğim gibi büyük frameworkleri indirin inceleyin.




  • quote:

    Orijinalden alıntı: Kaygerya

    quote:

    Orijinalden alıntı: Kod_Dünyası

    KAVGA ETMEYİN :)

    zaten şu sayfadaki
    http://forum.donanimhaber.com/m_70873467/tm.htm
    yorumunu okuduktan sonra kavgayı bırak kaale almam :)

    Benim o sayfada yorumum yok ki. Ya da ben mi göremiyorum..
  • quote:

    Orijinalden alıntı: Kaygerya

    quote:

    Orijinalden alıntı: zjnan

    quote:

    Orijinalden alıntı: Kaygerya

    quote:

    Orijinalden alıntı: zjnan

    quote:

    Orijinalden alıntı: Kaygerya

    quote:

    Orijinalden alıntı: Kod_Dünyası

    KAVGA ETMEYİN :)

    zaten şu sayfadaki
    http://forum.donanimhaber.com/m_70873467/tm.htm
    yorumunu okuduktan sonra kavgayı bırak kaale almam :)

    Siz kaale almayın yine de ama,
    Bende E-Ticaret sitesi yapıyorum ama ne 3 sene mi alıyor ne yığınlarca zamanımı. Fakat ben sizi anlıyorum ne demek istediğinizi. Önce kurumla oturulur konuşulur. 3 ay 4 ay proje hakkında toplantılar yapılır artık en son aşama platform da çalışma olayıdır. Ben de diyorum ki o kod yazma bölümü artık 1 aylık bir olaydır. Konuşup planladığınızı kağıda dökeceksiniz. Bundan da basiti olmaması gerek heralde bir yazılımcı için.
    Entity Framework'ü yeni tanıştığım falandan değil sadece ondan bahsetmek istedim. Siz Framework kurmucaksınız Framework ile çalışıcaksanız. Siz kendi framework'ünüzü yapma olayını bahsediyor iseniz , evet daha uzun süreçler bizi bekler. Dediğiniz gibi framework'ün hazır olanları kullanmak yeterlidir. Özel bir durumda da bence çokta sıkıntı yaratacağını düşünmüyorum.

    Ayrıca verdiğiniz linkteki yorumum da ne gördünüz ki kaale almayacaksınız ?

    programın exesi 4 mb mış.

    Eğer o linke giderseniz yaptığım yorum da ne demek istediğimi anlarsınız. Orada ki espiriyi gerisini okusaydınız eminim ki anlardınız.

    arkadaşım , yanlış anlama. anladıgım kadarıyla teknolojiyi takip eden , yenilikler ile ilgilenen bir üniversite öğrencisinsin. sen hangi yolda isen , bizde geçtik o yollardan. değişik konularda insanlara yardı metme çabanı da gördüm. hatta soylediklerimin sert olmasına rağmen efendice cevap vermişsin , saygı duydum. ancak senin içinde oldugun kısmı geçtim , kendi tecrübelerimi edindim , ve bir noktaya geldim. sadece tanımadıgınız insanların bilgi-tecrübesi hakkında yorum yapmayın, yanılırsınız. birde dediğim gibi büyük frameworkleri indirin inceleyin.

    Elimden geldiğince yeni teknolojilere açığım ama. İnsanların bilgelerine de yorum yapmıyorum , ben sadece bildiklerimle karşılaştırıp olabilecekleri söylüyorum. Framework'leri evet inceliyorum. Özellikle NHibernate gibi yeni olan teknolojilere de bakıyorum deyiniyorum. Ama aslında ben sizin framework yazmak yoksa kullanmak mı konusunda ki fikrinizi anlamış değilim. Yazalım mı diyorsunuz , yoksa var olan kütüphaneleri mi kullanalım diyorsunuz ?




  • quote:

    Orijinalden alıntı: zjnan

    quote:

    Orijinalden alıntı: Kaygerya

    e ticaret işi yapacaksanız neden herşeyi tanımlayasınız ki , bir sürü framework var , size en cok hitap edeni kullanabilirsiniz. oturup 0 dan database tabloları servisler , fonksiyonlar , 1 sene kaybettirir size. her alanda bu böyle.

    1 sene mi. Senin bu dediklerini adam akıllı bir projeye dökmek yaklaşık 1.5-2 hafta diye bilirim sana. Entity Framework denilen bir nimet var. Bilmediğiniz konular hakkında araştırıp yorum yapmanızı öneririm. Framework başlı başına bir nimet olsa da MVC de günümüzde ki en büyük yenilik getiren platform. Önceden bu yok muydu ? Tabi ki de vardı. Design Pattern mantığıyla çalışıldığında zaten tam anlamıyla MVC mantığıyla çalışmış oluyorsunuz. Dediğim gibi. Dediklerini hiç zor şeyler değil. Her zaman derim , yazılımcı için tasarım bölümü en uzun süren bölümdür. Geri kalan bölüm ise zevk işidir ve 2-3 güne yapılır biter gider :)

    Merhaba, sizin mesajınız üzerinden konuyla ilgili genel cevap vermeye çalışacağım.

    öncelikle sizin mesajınızla ilgili yazayım. Entity Framework denilen "nimet" ORM ( Object/releation mapping ) için kullanılan frameworklardan sadece bir tanesi. kavramın adından da anlaşılacağı üzere ilişkisel veritbanlarını ( rdbms örneğin: mssql, oracle vs. ) nesne paradigmasına aktarmak için kullanılıyor. Bu nimet nosql gibi ilişkisel olmayan veritabanı kullanılan senaryolar için kullanışsız. MVC de bir platform değil bir yazılım geliştirme paradigması ya da mimari şablonu ( architectural pattern ) olarak tanımlanabilir. Design pattern ile mvc ile birbiri ile alakasız kavramlar. N tane farklı tasarım şablonu kullanırsınız ama mvc mimarisinde iş yapmazsınız, tersi de geçerli. Yazılımın tasarım bölümü de hem teoride hem de pratikte en uzun bölümü değildir genelde. Eskiden unified processing model ya da waterfall gibi yöntemlerle uzun uzadıya tasarım yapılırdı ki bu projenin - desteksiz sallıyorum - %10 unu falan aşmazdı. Günüzümde populer olan çevik yöntemlerde ise tasarım - kodlama - test şeklinde bir iteratif süreç kullanılıyor burada da genelde en uzun iş test kodunu yazmak.

    başlığın içeriğine dönersek eğer, framework kullanımı türkiyede son yıllarda çok yaygın. php ve ms platformları hakkında bilgim olmasa da java için konuşursak eğer spring bu konudaki en yaygın platformdu işler biraz tersine döndü onu da aşağıda açıklamaya çalışacağım.
    frameworklerin çıkış sebebi diğer arkadaşların da bahsettiği gibi sık yapılan işleri kolay yapmak, tekerleği yeniden keşfetmemekti. Bunun için önceleri doğal olarak sıkça yapılan işlerin bir yere toplandığı kütüphaneler kullanılıyordu, işin yapılması pratikti ama sorun yapılma şekli yani her yiğidin yoğurt yiyişinin ayrı olmasıydı. işte bu sebepten ötürü abilerin kafasında tıpkı tasarım şablonlarının olduğu gibi mimari şablonların da olması gerektiği fikri oluştu.

    framework kullanmak bir nevi iki yüzü keskin kılıç, sebebini açıklamak için biraz geçmiş günlerden bahsederek örnek vereceğim. 2003 sonu 2004 yılıydı sanırım tl den 6 sıfır atılacağının haberi geldiğinde mevcut yazılımımızı bunun için güncellerken server-client yapımızı da web tabanlı hale getirelim demişti o zamanki patron. ucu bucağı olmayan bir yazılımı taşırken biz de tekerleği yeniden keşfetmek istemediğimiz için araştırmalarımız sonucu mvc için ilk örneklerinden birisi olan struts framework unu seçmiştik. herşey iyi güzel gibi gözüküyordu ilk başta. model kısmını java da yazmayarak sp ye bağlayıp xml tabanlı configler yaparak. Rod Johnson reyiz henüz yeni yayınlamıştı J2EE Development Without EJB kitabını, spring'in ipuçlarını vermişti ama ortalıkta henüz somut birşey yoktu.
    Neyse, struts kullanarak projeyi iyi kötü geliştirdik fakat gün gelip de struts 1.1 den 1.2 ye geçmek gerektiğinde ortalık karıştı birden. bütün projenin omurgası bu yapı olduğu için, bu yapı üzerinde dünya kadar custom component geliştirdiğimiz için ortalık yangın yerine döndü. minör bir versiyon güncellemesi olsa da ciddi değişiklikler içeriyordu bugları da cabasıydı ( 2 tane bugfix yaptığım için bir dönemler benim de adım vardı contributerlar arasında, genç yaşta hava atardım bununla hey gidi günler ) işte o an herkesin bahsettiği framework kullanma dezavantıjını bizzat yaşadım. laf kalabalığını geçersek eğer insanlar framework kullandığında genelde robotlaşıyorlar, sadece framework'ün onlara sağladığı çerçevede çalışmaya başlıyorlar ve işin özünü sorgulamıyorlar. bununla beraber framework kullanımı ile ilgili öğrendikleri kalıpların dışına da çıkmıyorlar. bir developer onlara hasbelkader bir yöntem öğretmişse/öğrenmişse onu kullanmaya devem ediyorlar. kullanılan framework lerin versiyon update lerinde ciddi testler ve geliştirmeler yapmak gerekebiliyor fakat bu yapılmadığından genelde eski teknoloji ile devam ediliyor. mesela bahsettiğim yazılım günümüzde kullanılıyor hala struts 1.2 ile. ben projenin içeirsinde değilim artık ama 2.0'a geçirmek imkansızdır herhalde.

    yukarıda bahsettiğim işlerin tersine dönmesi pozisyonuna gelirsek, 6-7 sene önce spring java dünyasına bir güneş gibi doğdu. context çekirdeği etrafında yer alan bir sürü modülü ile beraber java dünyasında derli toplu iş geliştirmek için neredeyse standart oldu. hem öğrenmesi kolay, hem pek çok ihtiyaca cevap veren, hem de bug ları az olan şahane bir ortamdı. benim de uzun yıllar münasabetim oldu kendisi ile. java nın da opensource olması ile ( geliştirme ortamının, jdk'nın opensource olması desek daha mantıklı aslında ) javanın geleceği artık herkesin söz sahibi olabildiği bir ortama dönüştü ve çoğu insanın beklentiği spring içeirisinde bulunan çoğu özelliğin artık java nın içerisinde gelmesi gerektiği idi. bunun sonucu olarak da java enterprise edition version 6 dan itibaren çoğu özelliği bu platform içerisinde interface olarak gelmeye başladı, standartları belirlendi farklı kurumlar bunun için farklı implementasyonlar yazdı. ( misal cdi için jsr 299, jsr 330 yayınlandı jboss weld, apache OpenWebBeans implementasyonlarını çıkardı ) durum böyle değişince Rod Johnson reyiz ( spring'in fikir babası, mimarı, programcısı herşeyi idi ) bile Spring projesini bırakıp scala ile uğraşmaya başladı. java platformu hala yazılım geliştirme dünyası için adımları ilk önce atıyor diğerleri bunu takip ediyor ( mvc, orm gibi kavramlar örnek gösterilebilir bunun için ) bu sebepten diğer platformlar da yavaş yavaş kendi içlerinde frameworklerin sağladığı kolaylıkları sağlayacaktır. Gerçi .net platformu zaten dışarıya açık değil o istisna bu konuda.

    bu kadar masalı bir kenara bırakırsak eğe, frameworkler iyidir güzeldir ama tehlikelidir de. alet kutunuzda sadece çekiç var ise heşeyi çivi olarak görmeye başlarsınız, frameworkler de bu ilüzyonu yaratır insanda.
    şimdiye kadar java ile iligli pek çok framework kullanmış, struts, hibernate gibi populerlerine katkı yapmış birisi olarak nacizane fikrim şudur ki yazılım gibi hergün değişen gelişen bir ekosistem içerisinde frameworklerden ziyada standartlar takip edilmeli ( java için jsr bunlar, diğer platformlarda nedir bilmiyorum ) işler kolaylıkla halledilirken "nasıl oluyorda oluyor" diye sorularak işin mantığı kavranmalı.




  • quote:

    Orijinalden alıntı: bestanealtcizgi

    quote:

    Orijinalden alıntı: zjnan

    quote:

    Orijinalden alıntı: Kaygerya

    e ticaret işi yapacaksanız neden herşeyi tanımlayasınız ki , bir sürü framework var , size en cok hitap edeni kullanabilirsiniz. oturup 0 dan database tabloları servisler , fonksiyonlar , 1 sene kaybettirir size. her alanda bu böyle.

    1 sene mi. Senin bu dediklerini adam akıllı bir projeye dökmek yaklaşık 1.5-2 hafta diye bilirim sana. Entity Framework denilen bir nimet var. Bilmediğiniz konular hakkında araştırıp yorum yapmanızı öneririm. Framework başlı başına bir nimet olsa da MVC de günümüzde ki en büyük yenilik getiren platform. Önceden bu yok muydu ? Tabi ki de vardı. Design Pattern mantığıyla çalışıldığında zaten tam anlamıyla MVC mantığıyla çalışmış oluyorsunuz. Dediğim gibi. Dediklerini hiç zor şeyler değil. Her zaman derim , yazılımcı için tasarım bölümü en uzun süren bölümdür. Geri kalan bölüm ise zevk işidir ve 2-3 güne yapılır biter gider :)

    Merhaba, sizin mesajınız üzerinden konuyla ilgili genel cevap vermeye çalışacağım.

    öncelikle sizin mesajınızla ilgili yazayım. Entity Framework denilen "nimet" ORM ( Object/releation mapping ) için kullanılan frameworklardan sadece bir tanesi. kavramın adından da anlaşılacağı üzere ilişkisel veritbanlarını ( rdbms örneğin: mssql, oracle vs. ) nesne paradigmasına aktarmak için kullanılıyor. Bu nimet nosql gibi ilişkisel olmayan veritabanı kullanılan senaryolar için kullanışsız. MVC de bir platform değil bir yazılım geliştirme paradigması ya da mimari şablonu ( architectural pattern ) olarak tanımlanabilir. Design pattern ile mvc ile birbiri ile alakasız kavramlar. N tane farklı tasarım şablonu kullanırsınız ama mvc mimarisinde iş yapmazsınız, tersi de geçerli. Yazılımın tasarım bölümü de hem teoride hem de pratikte en uzun bölümü değildir genelde. Eskiden unified processing model ya da waterfall gibi yöntemlerle uzun uzadıya tasarım yapılırdı ki bu projenin - desteksiz sallıyorum - %10 unu falan aşmazdı. Günüzümde populer olan çevik yöntemlerde ise tasarım - kodlama - test şeklinde bir iteratif süreç kullanılıyor burada da genelde en uzun iş test kodunu yazmak.

    başlığın içeriğine dönersek eğer, framework kullanımı türkiyede son yıllarda çok yaygın. php ve ms platformları hakkında bilgim olmasa da java için konuşursak eğer spring bu konudaki en yaygın platformdu işler biraz tersine döndü onu da aşağıda açıklamaya çalışacağım.
    frameworklerin çıkış sebebi diğer arkadaşların da bahsettiği gibi sık yapılan işleri kolay yapmak, tekerleği yeniden keşfetmemekti. Bunun için önceleri doğal olarak sıkça yapılan işlerin bir yere toplandığı kütüphaneler kullanılıyordu, işin yapılması pratikti ama sorun yapılma şekli yani her yiğidin yoğurt yiyişinin ayrı olmasıydı. işte bu sebepten ötürü abilerin kafasında tıpkı tasarım şablonlarının olduğu gibi mimari şablonların da olması gerektiği fikri oluştu.

    framework kullanmak bir nevi iki yüzü keskin kılıç, sebebini açıklamak için biraz geçmiş günlerden bahsederek örnek vereceğim. 2003 sonu 2004 yılıydı sanırım tl den 6 sıfır atılacağının haberi geldiğinde mevcut yazılımımızı bunun için güncellerken server-client yapımızı da web tabanlı hale getirelim demişti o zamanki patron. ucu bucağı olmayan bir yazılımı taşırken biz de tekerleği yeniden keşfetmek istemediğimiz için araştırmalarımız sonucu mvc için ilk örneklerinden birisi olan struts framework unu seçmiştik. herşey iyi güzel gibi gözüküyordu ilk başta. model kısmını java da yazmayarak sp ye bağlayıp xml tabanlı configler yaparak. Rod Johnson reyiz henüz yeni yayınlamıştı J2EE Development Without EJB kitabını, spring'in ipuçlarını vermişti ama ortalıkta henüz somut birşey yoktu.
    Neyse, struts kullanarak projeyi iyi kötü geliştirdik fakat gün gelip de struts 1.1 den 1.2 ye geçmek gerektiğinde ortalık karıştı birden. bütün projenin omurgası bu yapı olduğu için, bu yapı üzerinde dünya kadar custom component geliştirdiğimiz için ortalık yangın yerine döndü. minör bir versiyon güncellemesi olsa da ciddi değişiklikler içeriyordu bugları da cabasıydı ( 2 tane bugfix yaptığım için bir dönemler benim de adım vardı contributerlar arasında, genç yaşta hava atardım bununla hey gidi günler ) işte o an herkesin bahsettiği framework kullanma dezavantıjını bizzat yaşadım. laf kalabalığını geçersek eğer insanlar framework kullandığında genelde robotlaşıyorlar, sadece framework'ün onlara sağladığı çerçevede çalışmaya başlıyorlar ve işin özünü sorgulamıyorlar. bununla beraber framework kullanımı ile ilgili öğrendikleri kalıpların dışına da çıkmıyorlar. bir developer onlara hasbelkader bir yöntem öğretmişse/öğrenmişse onu kullanmaya devem ediyorlar. kullanılan framework lerin versiyon update lerinde ciddi testler ve geliştirmeler yapmak gerekebiliyor fakat bu yapılmadığından genelde eski teknoloji ile devam ediliyor. mesela bahsettiğim yazılım günümüzde kullanılıyor hala struts 1.2 ile. ben projenin içeirsinde değilim artık ama 2.0'a geçirmek imkansızdır herhalde.

    yukarıda bahsettiğim işlerin tersine dönmesi pozisyonuna gelirsek, 6-7 sene önce spring java dünyasına bir güneş gibi doğdu. context çekirdeği etrafında yer alan bir sürü modülü ile beraber java dünyasında derli toplu iş geliştirmek için neredeyse standart oldu. hem öğrenmesi kolay, hem pek çok ihtiyaca cevap veren, hem de bug ları az olan şahane bir ortamdı. benim de uzun yıllar münasabetim oldu kendisi ile. java nın da opensource olması ile ( geliştirme ortamının, jdk'nın opensource olması desek daha mantıklı aslında ) javanın geleceği artık herkesin söz sahibi olabildiği bir ortama dönüştü ve çoğu insanın beklentiği spring içeirisinde bulunan çoğu özelliğin artık java nın içerisinde gelmesi gerektiği idi. bunun sonucu olarak da java enterprise edition version 6 dan itibaren çoğu özelliği bu platform içerisinde interface olarak gelmeye başladı, standartları belirlendi farklı kurumlar bunun için farklı implementasyonlar yazdı. ( misal cdi için jsr 299, jsr 330 yayınlandı jboss weld, apache OpenWebBeans implementasyonlarını çıkardı ) durum böyle değişince Rod Johnson reyiz ( spring'in fikir babası, mimarı, programcısı herşeyi idi ) bile Spring projesini bırakıp scala ile uğraşmaya başladı. java platformu hala yazılım geliştirme dünyası için adımları ilk önce atıyor diğerleri bunu takip ediyor ( mvc, orm gibi kavramlar örnek gösterilebilir bunun için ) bu sebepten diğer platformlar da yavaş yavaş kendi içlerinde frameworklerin sağladığı kolaylıkları sağlayacaktır. Gerçi .net platformu zaten dışarıya açık değil o istisna bu konuda.

    bu kadar masalı bir kenara bırakırsak eğe, frameworkler iyidir güzeldir ama tehlikelidir de. alet kutunuzda sadece çekiç var ise heşeyi çivi olarak görmeye başlarsınız, frameworkler de bu ilüzyonu yaratır insanda.
    şimdiye kadar java ile iligli pek çok framework kullanmış, struts, hibernate gibi populerlerine katkı yapmış birisi olarak nacizane fikrim şudur ki yazılım gibi hergün değişen gelişen bir ekosistem içerisinde frameworklerden ziyada standartlar takip edilmeli ( java için jsr bunlar, diğer platformlarda nedir bilmiyorum ) işler kolaylıkla halledilirken "nasıl oluyorda oluyor" diye sorularak işin mantığı kavranmalı.

    Artık evet Tasarım - Code ve popüleritesi artan Test kısmı şeklinde oluyor. Bu Test olayı çok yeni olmasına karşın hızla yayılıyor ve gayet iyide. Ama ben yine de diyorum ki bizler için Tasarım zor. Kod planı daha rahat yapabildiğimiz şeyler olsa da aslında projenin daha büyük yerini kaplasa da bizlere kısa geliyor diyerek düzelteyim ben orayı.
    ORM kullanımı ise günümüz de artık olmazsa olmazlar haline geldi. ORM şeklinde çalışmanın faydasını çok gördüm diye bilirim.
    Framework kullanırken de dediğiniz gibi dezavantajlarını göz önünde bulundurup kullanmak gerekir. Çünkü bizlere sağladığı yararların da ucu bucağı olmadığını hep birlikte görüyoruz.

    Ben yine de bu kadar şey anlatıp bizimle paylaştığın için teşekkür ederim.




  • quote:

    Orijinalden alıntı: zjnan

    quote:

    Orijinalden alıntı: bestanealtcizgi

    quote:

    Orijinalden alıntı: zjnan

    quote:

    Orijinalden alıntı: Kaygerya

    e ticaret işi yapacaksanız neden herşeyi tanımlayasınız ki , bir sürü framework var , size en cok hitap edeni kullanabilirsiniz. oturup 0 dan database tabloları servisler , fonksiyonlar , 1 sene kaybettirir size. her alanda bu böyle.

    1 sene mi. Senin bu dediklerini adam akıllı bir projeye dökmek yaklaşık 1.5-2 hafta diye bilirim sana. Entity Framework denilen bir nimet var. Bilmediğiniz konular hakkında araştırıp yorum yapmanızı öneririm. Framework başlı başına bir nimet olsa da MVC de günümüzde ki en büyük yenilik getiren platform. Önceden bu yok muydu ? Tabi ki de vardı. Design Pattern mantığıyla çalışıldığında zaten tam anlamıyla MVC mantığıyla çalışmış oluyorsunuz. Dediğim gibi. Dediklerini hiç zor şeyler değil. Her zaman derim , yazılımcı için tasarım bölümü en uzun süren bölümdür. Geri kalan bölüm ise zevk işidir ve 2-3 güne yapılır biter gider :)

    Merhaba, sizin mesajınız üzerinden konuyla ilgili genel cevap vermeye çalışacağım.

    öncelikle sizin mesajınızla ilgili yazayım. Entity Framework denilen "nimet" ORM ( Object/releation mapping ) için kullanılan frameworklardan sadece bir tanesi. kavramın adından da anlaşılacağı üzere ilişkisel veritbanlarını ( rdbms örneğin: mssql, oracle vs. ) nesne paradigmasına aktarmak için kullanılıyor. Bu nimet nosql gibi ilişkisel olmayan veritabanı kullanılan senaryolar için kullanışsız. MVC de bir platform değil bir yazılım geliştirme paradigması ya da mimari şablonu ( architectural pattern ) olarak tanımlanabilir. Design pattern ile mvc ile birbiri ile alakasız kavramlar. N tane farklı tasarım şablonu kullanırsınız ama mvc mimarisinde iş yapmazsınız, tersi de geçerli. Yazılımın tasarım bölümü de hem teoride hem de pratikte en uzun bölümü değildir genelde. Eskiden unified processing model ya da waterfall gibi yöntemlerle uzun uzadıya tasarım yapılırdı ki bu projenin - desteksiz sallıyorum - %10 unu falan aşmazdı. Günüzümde populer olan çevik yöntemlerde ise tasarım - kodlama - test şeklinde bir iteratif süreç kullanılıyor burada da genelde en uzun iş test kodunu yazmak.

    başlığın içeriğine dönersek eğer, framework kullanımı türkiyede son yıllarda çok yaygın. php ve ms platformları hakkında bilgim olmasa da java için konuşursak eğer spring bu konudaki en yaygın platformdu işler biraz tersine döndü onu da aşağıda açıklamaya çalışacağım.
    frameworklerin çıkış sebebi diğer arkadaşların da bahsettiği gibi sık yapılan işleri kolay yapmak, tekerleği yeniden keşfetmemekti. Bunun için önceleri doğal olarak sıkça yapılan işlerin bir yere toplandığı kütüphaneler kullanılıyordu, işin yapılması pratikti ama sorun yapılma şekli yani her yiğidin yoğurt yiyişinin ayrı olmasıydı. işte bu sebepten ötürü abilerin kafasında tıpkı tasarım şablonlarının olduğu gibi mimari şablonların da olması gerektiği fikri oluştu.

    framework kullanmak bir nevi iki yüzü keskin kılıç, sebebini açıklamak için biraz geçmiş günlerden bahsederek örnek vereceğim. 2003 sonu 2004 yılıydı sanırım tl den 6 sıfır atılacağının haberi geldiğinde mevcut yazılımımızı bunun için güncellerken server-client yapımızı da web tabanlı hale getirelim demişti o zamanki patron. ucu bucağı olmayan bir yazılımı taşırken biz de tekerleği yeniden keşfetmek istemediğimiz için araştırmalarımız sonucu mvc için ilk örneklerinden birisi olan struts framework unu seçmiştik. herşey iyi güzel gibi gözüküyordu ilk başta. model kısmını java da yazmayarak sp ye bağlayıp xml tabanlı configler yaparak. Rod Johnson reyiz henüz yeni yayınlamıştı J2EE Development Without EJB kitabını, spring'in ipuçlarını vermişti ama ortalıkta henüz somut birşey yoktu.
    Neyse, struts kullanarak projeyi iyi kötü geliştirdik fakat gün gelip de struts 1.1 den 1.2 ye geçmek gerektiğinde ortalık karıştı birden. bütün projenin omurgası bu yapı olduğu için, bu yapı üzerinde dünya kadar custom component geliştirdiğimiz için ortalık yangın yerine döndü. minör bir versiyon güncellemesi olsa da ciddi değişiklikler içeriyordu bugları da cabasıydı ( 2 tane bugfix yaptığım için bir dönemler benim de adım vardı contributerlar arasında, genç yaşta hava atardım bununla hey gidi günler ) işte o an herkesin bahsettiği framework kullanma dezavantıjını bizzat yaşadım. laf kalabalığını geçersek eğer insanlar framework kullandığında genelde robotlaşıyorlar, sadece framework'ün onlara sağladığı çerçevede çalışmaya başlıyorlar ve işin özünü sorgulamıyorlar. bununla beraber framework kullanımı ile ilgili öğrendikleri kalıpların dışına da çıkmıyorlar. bir developer onlara hasbelkader bir yöntem öğretmişse/öğrenmişse onu kullanmaya devem ediyorlar. kullanılan framework lerin versiyon update lerinde ciddi testler ve geliştirmeler yapmak gerekebiliyor fakat bu yapılmadığından genelde eski teknoloji ile devam ediliyor. mesela bahsettiğim yazılım günümüzde kullanılıyor hala struts 1.2 ile. ben projenin içeirsinde değilim artık ama 2.0'a geçirmek imkansızdır herhalde.

    yukarıda bahsettiğim işlerin tersine dönmesi pozisyonuna gelirsek, 6-7 sene önce spring java dünyasına bir güneş gibi doğdu. context çekirdeği etrafında yer alan bir sürü modülü ile beraber java dünyasında derli toplu iş geliştirmek için neredeyse standart oldu. hem öğrenmesi kolay, hem pek çok ihtiyaca cevap veren, hem de bug ları az olan şahane bir ortamdı. benim de uzun yıllar münasabetim oldu kendisi ile. java nın da opensource olması ile ( geliştirme ortamının, jdk'nın opensource olması desek daha mantıklı aslında ) javanın geleceği artık herkesin söz sahibi olabildiği bir ortama dönüştü ve çoğu insanın beklentiği spring içeirisinde bulunan çoğu özelliğin artık java nın içerisinde gelmesi gerektiği idi. bunun sonucu olarak da java enterprise edition version 6 dan itibaren çoğu özelliği bu platform içerisinde interface olarak gelmeye başladı, standartları belirlendi farklı kurumlar bunun için farklı implementasyonlar yazdı. ( misal cdi için jsr 299, jsr 330 yayınlandı jboss weld, apache OpenWebBeans implementasyonlarını çıkardı ) durum böyle değişince Rod Johnson reyiz ( spring'in fikir babası, mimarı, programcısı herşeyi idi ) bile Spring projesini bırakıp scala ile uğraşmaya başladı. java platformu hala yazılım geliştirme dünyası için adımları ilk önce atıyor diğerleri bunu takip ediyor ( mvc, orm gibi kavramlar örnek gösterilebilir bunun için ) bu sebepten diğer platformlar da yavaş yavaş kendi içlerinde frameworklerin sağladığı kolaylıkları sağlayacaktır. Gerçi .net platformu zaten dışarıya açık değil o istisna bu konuda.

    bu kadar masalı bir kenara bırakırsak eğe, frameworkler iyidir güzeldir ama tehlikelidir de. alet kutunuzda sadece çekiç var ise heşeyi çivi olarak görmeye başlarsınız, frameworkler de bu ilüzyonu yaratır insanda.
    şimdiye kadar java ile iligli pek çok framework kullanmış, struts, hibernate gibi populerlerine katkı yapmış birisi olarak nacizane fikrim şudur ki yazılım gibi hergün değişen gelişen bir ekosistem içerisinde frameworklerden ziyada standartlar takip edilmeli ( java için jsr bunlar, diğer platformlarda nedir bilmiyorum ) işler kolaylıkla halledilirken "nasıl oluyorda oluyor" diye sorularak işin mantığı kavranmalı.

    Artık evet Tasarım - Code ve popüleritesi artan Test kısmı şeklinde oluyor. Bu Test olayı çok yeni olmasına karşın hızla yayılıyor ve gayet iyide. Ama ben yine de diyorum ki bizler için Tasarım zor. Kod planı daha rahat yapabildiğimiz şeyler olsa da aslında projenin daha büyük yerini kaplasa da bizlere kısa geliyor diyerek düzelteyim ben orayı.
    ORM kullanımı ise günümüz de artık olmazsa olmazlar haline geldi. ORM şeklinde çalışmanın faydasını çok gördüm diye bilirim.
    Framework kullanırken de dediğiniz gibi dezavantajlarını göz önünde bulundurup kullanmak gerekir. Çünkü bizlere sağladığı yararların da ucu bucağı olmadığını hep birlikte görüyoruz.

    Ben yine de bu kadar şey anlatıp bizimle paylaştığın için teşekkür ederim.

    "yeni" göreceli bir kavram aslında ama sizin yeni diye tabir ettiğiniz çoğu kavram yazılım için eski sayılabilecek bir süredir var. "Test olayı" diye tabir ettiğiniz test driven development türkiyede bile 2006 yılında deli gibi kullanılıyordu. "yeni" den ziyade "yaygın olmayan" demek daha doğru bir tanımlama olabilir.

    Tasarım ise süreden ziyada önemli/önceliği yüksek/kritik bir konu. tasarım seviyesinde yapılan bir hata/eksiklik proje release olduktan sonra düzeltilmesi en zor ve en maliyetli olan hatalardan bitanesi. Kısa gelmesinden çok "kervan yolda düzülür" ( agile'in türkiyede en büyük yanlış anlaşılması bu da ) mantığı ile işler yapıldığı için memleketimde gereken önem verilmiyor.

    ORM olmazsa olmazdan ziyade modası geçmiş bir durumda şu an dünya genelinde. Özellikle web tabanlı projeler için artık nosql veritabanlarını yöneliyor insanlar bunlar için de orm kullanılamıyor doğası gereği. kullandığınız entity framework'ün rol modeli olan hibernate projesinin başındaki adam olan Gavin King bile bıraktı hibernate ile uğraşmayı. Ayrıca ORM gibi araya başka bir abstraction layer ( bunu türkçeye nasıl çeviririz bilmiyorum soyutlama katmanı desem ne kadar doğrudur bilemem ) sokmak hem projeyi hantallaştırıyor/yavaşlatıyor hem de veritabanında yapılan basit değişikliklerde bile refactor edilmesi gereken bir sürü kod oluyor. Hibernate xml yerine annotation tabanlı config ile bunu biraz toparlamıştı .net tarafında durum nedir bilmiyorum ama sırf bu refactoringi yapmayı göze alamadıkları için saçma sapan workaround uyduran çok durum gördüm. Ama bütün bunlara rağmen rdbms ile çalışacaksam ve nesneye yönelik bir programlama dili kullancaksam her zaman ORM kullanmayı tercih ederim.

    framework iyidir güzeldir, kullanılmalıdır gereksiz zaman harcamamak için ama fanatiklik yapılmadan, bizi karanlık tarafa geçirmesine izin vermeden.




  • quote:

    Orijinalden alıntı: bestanealtcizgi

    quote:

    Orijinalden alıntı: zjnan

    quote:

    Orijinalden alıntı: bestanealtcizgi

    quote:

    Orijinalden alıntı: zjnan

    quote:

    Orijinalden alıntı: Kaygerya

    e ticaret işi yapacaksanız neden herşeyi tanımlayasınız ki , bir sürü framework var , size en cok hitap edeni kullanabilirsiniz. oturup 0 dan database tabloları servisler , fonksiyonlar , 1 sene kaybettirir size. her alanda bu böyle.

    1 sene mi. Senin bu dediklerini adam akıllı bir projeye dökmek yaklaşık 1.5-2 hafta diye bilirim sana. Entity Framework denilen bir nimet var. Bilmediğiniz konular hakkında araştırıp yorum yapmanızı öneririm. Framework başlı başına bir nimet olsa da MVC de günümüzde ki en büyük yenilik getiren platform. Önceden bu yok muydu ? Tabi ki de vardı. Design Pattern mantığıyla çalışıldığında zaten tam anlamıyla MVC mantığıyla çalışmış oluyorsunuz. Dediğim gibi. Dediklerini hiç zor şeyler değil. Her zaman derim , yazılımcı için tasarım bölümü en uzun süren bölümdür. Geri kalan bölüm ise zevk işidir ve 2-3 güne yapılır biter gider :)

    Merhaba, sizin mesajınız üzerinden konuyla ilgili genel cevap vermeye çalışacağım.

    öncelikle sizin mesajınızla ilgili yazayım. Entity Framework denilen "nimet" ORM ( Object/releation mapping ) için kullanılan frameworklardan sadece bir tanesi. kavramın adından da anlaşılacağı üzere ilişkisel veritbanlarını ( rdbms örneğin: mssql, oracle vs. ) nesne paradigmasına aktarmak için kullanılıyor. Bu nimet nosql gibi ilişkisel olmayan veritabanı kullanılan senaryolar için kullanışsız. MVC de bir platform değil bir yazılım geliştirme paradigması ya da mimari şablonu ( architectural pattern ) olarak tanımlanabilir. Design pattern ile mvc ile birbiri ile alakasız kavramlar. N tane farklı tasarım şablonu kullanırsınız ama mvc mimarisinde iş yapmazsınız, tersi de geçerli. Yazılımın tasarım bölümü de hem teoride hem de pratikte en uzun bölümü değildir genelde. Eskiden unified processing model ya da waterfall gibi yöntemlerle uzun uzadıya tasarım yapılırdı ki bu projenin - desteksiz sallıyorum - %10 unu falan aşmazdı. Günüzümde populer olan çevik yöntemlerde ise tasarım - kodlama - test şeklinde bir iteratif süreç kullanılıyor burada da genelde en uzun iş test kodunu yazmak.

    başlığın içeriğine dönersek eğer, framework kullanımı türkiyede son yıllarda çok yaygın. php ve ms platformları hakkında bilgim olmasa da java için konuşursak eğer spring bu konudaki en yaygın platformdu işler biraz tersine döndü onu da aşağıda açıklamaya çalışacağım.
    frameworklerin çıkış sebebi diğer arkadaşların da bahsettiği gibi sık yapılan işleri kolay yapmak, tekerleği yeniden keşfetmemekti. Bunun için önceleri doğal olarak sıkça yapılan işlerin bir yere toplandığı kütüphaneler kullanılıyordu, işin yapılması pratikti ama sorun yapılma şekli yani her yiğidin yoğurt yiyişinin ayrı olmasıydı. işte bu sebepten ötürü abilerin kafasında tıpkı tasarım şablonlarının olduğu gibi mimari şablonların da olması gerektiği fikri oluştu.

    framework kullanmak bir nevi iki yüzü keskin kılıç, sebebini açıklamak için biraz geçmiş günlerden bahsederek örnek vereceğim. 2003 sonu 2004 yılıydı sanırım tl den 6 sıfır atılacağının haberi geldiğinde mevcut yazılımımızı bunun için güncellerken server-client yapımızı da web tabanlı hale getirelim demişti o zamanki patron. ucu bucağı olmayan bir yazılımı taşırken biz de tekerleği yeniden keşfetmek istemediğimiz için araştırmalarımız sonucu mvc için ilk örneklerinden birisi olan struts framework unu seçmiştik. herşey iyi güzel gibi gözüküyordu ilk başta. model kısmını java da yazmayarak sp ye bağlayıp xml tabanlı configler yaparak. Rod Johnson reyiz henüz yeni yayınlamıştı J2EE Development Without EJB kitabını, spring'in ipuçlarını vermişti ama ortalıkta henüz somut birşey yoktu.
    Neyse, struts kullanarak projeyi iyi kötü geliştirdik fakat gün gelip de struts 1.1 den 1.2 ye geçmek gerektiğinde ortalık karıştı birden. bütün projenin omurgası bu yapı olduğu için, bu yapı üzerinde dünya kadar custom component geliştirdiğimiz için ortalık yangın yerine döndü. minör bir versiyon güncellemesi olsa da ciddi değişiklikler içeriyordu bugları da cabasıydı ( 2 tane bugfix yaptığım için bir dönemler benim de adım vardı contributerlar arasında, genç yaşta hava atardım bununla hey gidi günler ) işte o an herkesin bahsettiği framework kullanma dezavantıjını bizzat yaşadım. laf kalabalığını geçersek eğer insanlar framework kullandığında genelde robotlaşıyorlar, sadece framework'ün onlara sağladığı çerçevede çalışmaya başlıyorlar ve işin özünü sorgulamıyorlar. bununla beraber framework kullanımı ile ilgili öğrendikleri kalıpların dışına da çıkmıyorlar. bir developer onlara hasbelkader bir yöntem öğretmişse/öğrenmişse onu kullanmaya devem ediyorlar. kullanılan framework lerin versiyon update lerinde ciddi testler ve geliştirmeler yapmak gerekebiliyor fakat bu yapılmadığından genelde eski teknoloji ile devam ediliyor. mesela bahsettiğim yazılım günümüzde kullanılıyor hala struts 1.2 ile. ben projenin içeirsinde değilim artık ama 2.0'a geçirmek imkansızdır herhalde.

    yukarıda bahsettiğim işlerin tersine dönmesi pozisyonuna gelirsek, 6-7 sene önce spring java dünyasına bir güneş gibi doğdu. context çekirdeği etrafında yer alan bir sürü modülü ile beraber java dünyasında derli toplu iş geliştirmek için neredeyse standart oldu. hem öğrenmesi kolay, hem pek çok ihtiyaca cevap veren, hem de bug ları az olan şahane bir ortamdı. benim de uzun yıllar münasabetim oldu kendisi ile. java nın da opensource olması ile ( geliştirme ortamının, jdk'nın opensource olması desek daha mantıklı aslında ) javanın geleceği artık herkesin söz sahibi olabildiği bir ortama dönüştü ve çoğu insanın beklentiği spring içeirisinde bulunan çoğu özelliğin artık java nın içerisinde gelmesi gerektiği idi. bunun sonucu olarak da java enterprise edition version 6 dan itibaren çoğu özelliği bu platform içerisinde interface olarak gelmeye başladı, standartları belirlendi farklı kurumlar bunun için farklı implementasyonlar yazdı. ( misal cdi için jsr 299, jsr 330 yayınlandı jboss weld, apache OpenWebBeans implementasyonlarını çıkardı ) durum böyle değişince Rod Johnson reyiz ( spring'in fikir babası, mimarı, programcısı herşeyi idi ) bile Spring projesini bırakıp scala ile uğraşmaya başladı. java platformu hala yazılım geliştirme dünyası için adımları ilk önce atıyor diğerleri bunu takip ediyor ( mvc, orm gibi kavramlar örnek gösterilebilir bunun için ) bu sebepten diğer platformlar da yavaş yavaş kendi içlerinde frameworklerin sağladığı kolaylıkları sağlayacaktır. Gerçi .net platformu zaten dışarıya açık değil o istisna bu konuda.

    bu kadar masalı bir kenara bırakırsak eğe, frameworkler iyidir güzeldir ama tehlikelidir de. alet kutunuzda sadece çekiç var ise heşeyi çivi olarak görmeye başlarsınız, frameworkler de bu ilüzyonu yaratır insanda.
    şimdiye kadar java ile iligli pek çok framework kullanmış, struts, hibernate gibi populerlerine katkı yapmış birisi olarak nacizane fikrim şudur ki yazılım gibi hergün değişen gelişen bir ekosistem içerisinde frameworklerden ziyada standartlar takip edilmeli ( java için jsr bunlar, diğer platformlarda nedir bilmiyorum ) işler kolaylıkla halledilirken "nasıl oluyorda oluyor" diye sorularak işin mantığı kavranmalı.

    Artık evet Tasarım - Code ve popüleritesi artan Test kısmı şeklinde oluyor. Bu Test olayı çok yeni olmasına karşın hızla yayılıyor ve gayet iyide. Ama ben yine de diyorum ki bizler için Tasarım zor. Kod planı daha rahat yapabildiğimiz şeyler olsa da aslında projenin daha büyük yerini kaplasa da bizlere kısa geliyor diyerek düzelteyim ben orayı.
    ORM kullanımı ise günümüz de artık olmazsa olmazlar haline geldi. ORM şeklinde çalışmanın faydasını çok gördüm diye bilirim.
    Framework kullanırken de dediğiniz gibi dezavantajlarını göz önünde bulundurup kullanmak gerekir. Çünkü bizlere sağladığı yararların da ucu bucağı olmadığını hep birlikte görüyoruz.

    Ben yine de bu kadar şey anlatıp bizimle paylaştığın için teşekkür ederim.

    "yeni" göreceli bir kavram aslında ama sizin yeni diye tabir ettiğiniz çoğu kavram yazılım için eski sayılabilecek bir süredir var. "Test olayı" diye tabir ettiğiniz test driven development türkiyede bile 2006 yılında deli gibi kullanılıyordu. "yeni" den ziyade "yaygın olmayan" demek daha doğru bir tanımlama olabilir.

    Tasarım ise süreden ziyada önemli/önceliği yüksek/kritik bir konu. tasarım seviyesinde yapılan bir hata/eksiklik proje release olduktan sonra düzeltilmesi en zor ve en maliyetli olan hatalardan bitanesi. Kısa gelmesinden çok "kervan yolda düzülür" ( agile'in türkiyede en büyük yanlış anlaşılması bu da ) mantığı ile işler yapıldığı için memleketimde gereken önem verilmiyor.

    ORM olmazsa olmazdan ziyade modası geçmiş bir durumda şu an dünya genelinde. Özellikle web tabanlı projeler için artık nosql veritabanlarını yöneliyor insanlar bunlar için de orm kullanılamıyor doğası gereği. kullandığınız entity framework'ün rol modeli olan hibernate projesinin başındaki adam olan Gavin King bile bıraktı hibernate ile uğraşmayı. Ayrıca ORM gibi araya başka bir abstraction layer ( bunu türkçeye nasıl çeviririz bilmiyorum soyutlama katmanı desem ne kadar doğrudur bilemem ) sokmak hem projeyi hantallaştırıyor/yavaşlatıyor hem de veritabanında yapılan basit değişikliklerde bile refactor edilmesi gereken bir sürü kod oluyor. Hibernate xml yerine annotation tabanlı config ile bunu biraz toparlamıştı .net tarafında durum nedir bilmiyorum ama sırf bu refactoringi yapmayı göze alamadıkları için saçma sapan workaround uyduran çok durum gördüm. Ama bütün bunlara rağmen rdbms ile çalışacaksam ve nesneye yönelik bir programlama dili kullancaksam her zaman ORM kullanmayı tercih ederim.

    framework iyidir güzeldir, kullanılmalıdır gereksiz zaman harcamamak için ama fanatiklik yapılmadan, bizi karanlık tarafa geçirmesine izin vermeden.

    Dediğiniz gibi yeni den ziyade yaygın olmayan demek daha doğruydu. ORM evet modası geçmiş bir durum ama nesneye yönelik olduğundan hale vazgeçilmezlerden biri diye biliriz hala.

    Neyse daha da konuyu uzatmaya gerek yok. Zaten siz gerekli olan her şeyi açıklamışsınız. Yeniden teşekkür ederim.




  • frameworklerin dokumantasyonlarını okuyup , ve omurgasına , geliştirme esaslarına sadık kalarak , kod içine girmeden mumkunse if şöyle ise söyle yap diye hardcode etmeden , gelebilecek güncellemeler , geliştirmeler ve sektör gidişatına bağlı olarak , küçük plugin , webpart modül vs gibi seviyelerde gerekli geliştirmeleri yapmak , frameworku sadece altyapı olarak görüp sadece tanımlamalar servisler ve fonksiyonlar seviyesinde görüp , davranmak gerekli. Ben framework kullanma taraftarıyım. ancak framework eçok bağımlı kalmadan , playgroundda sadece kullanıp , arka planda framework omurgasına sadık kalarak framework geliştirmeleri - özelleştirmeleri yapmak bana daha mantıklı geliyor. çünkü frameworklerin önemli avantajlarından birkaçı :
    1) A frameworkunu kullanan bir projedye yeni bir eleman gerekiyor , A frameworkunu bilen birisi almak i şirket sahibinin işine geliyor. sonucta projeye daha kolay adapte oluyor, ve hemen geliştirmeye devam edebiliyor
    2) Sizi pek çok gereksinim analizi , sektör ihtiyaçlarının tanımlanması gibi maliyetlerden kurtarıyor çünkü zaten sektörün ihtiyaçları düşünülerek geliştirmiş bir framework oluyor.
    3) Opensource bir frameworkte siz de geliştirmelere dahil olabiliyorsunuz. bunun da yeri ayrı :)




  • quote:

    Orijinalden alıntı: Kaygerya

    frameworklerin dokumantasyonlarını okuyup , ve omurgasına , geliştirme esaslarına sadık kalarak , kod içine girmeden mumkunse if şöyle ise söyle yap diye hardcode etmeden , gelebilecek güncellemeler , geliştirmeler ve sektör gidişatına bağlı olarak , küçük plugin , webpart modül vs gibi seviyelerde gerekli geliştirmeleri yapmak , frameworku sadece altyapı olarak görüp sadece tanımlamalar servisler ve fonksiyonlar seviyesinde görüp , davranmak gerekli. Ben framework kullanma taraftarıyım. ancak framework eçok bağımlı kalmadan , playgroundda sadece kullanıp , arka planda framework omurgasına sadık kalarak framework geliştirmeleri - özelleştirmeleri yapmak bana daha mantıklı geliyor. çünkü frameworklerin önemli avantajlarından birkaçı :
    1) A frameworkunu kullanan bir projedye yeni bir eleman gerekiyor , A frameworkunu bilen birisi almak i şirket sahibinin işine geliyor. sonucta projeye daha kolay adapte oluyor, ve hemen geliştirmeye devam edebiliyor
    2) Sizi pek çok gereksinim analizi , sektör ihtiyaçlarının tanımlanması gibi maliyetlerden kurtarıyor çünkü zaten sektörün ihtiyaçları düşünülerek geliştirmiş bir framework oluyor.
    3) Opensource bir frameworkte siz de geliştirmelere dahil olabiliyorsunuz. bunun da yeri ayrı :)

    Kesinlikle 1. maddeye katılıyorum. Bilen birisini alıyorsunuz ve hemen adapte olup geliştirmeye devam ediyor. Framework için dediklerinize katılıyorum ama piyasa da 1. madde yeterince önemli bir yerde.




  • 
Sayfa: 1
- x
Bildirim
mesajınız kopyalandı (ctrl+v) yapıştırmak istediğiniz yere yapıştırabilirsiniz.