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

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.

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 :)

quote:

Orijinalden alıntı: Kod_Dünyası

KAVGA ETMEYİN :)

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 :)

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 ?

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ış.

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.

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 :)

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.

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 :)

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ı.

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.

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.

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ı :)