Bu soru, Web tabanlı Çerçeveler kullanmanın avantaj ve dezavantajlarını ortaya çıkarmaya odaklanmıştır : Cake PHP, Zend, jQuery, ASP.NET gibi). Bu soru tamamen dil bilincidir . "Devlerin omuzlarında durmak " kavramıyla başlayayım .

Avantajları:

• Geliştiricileri Güçlendirir - daha önce 100 satır kod almış olabilecek özellikleri alarak ve bunları basit bir fonksiyona sıkıştırarak geliştiricilere Web Sitelerine daha karmaşık özellikler entegre etmeleri için güç verir.
• Uygulamaların daha hızlı geliştirilmesine izin ver - bu, çok küçük bir pencerede oluşturulmuş web sitelerine ihtiyaç duyan insanlar için çok önemlidir (bunun herhangi bir örneği var mı?)
• Daha Düşük Maliyetler - programcıların maliyet tasarruflarını müşteriye geçirmelerine olanak tanır, bir web sitesi isteyen ancak daha önce daha yüksek geliştirme maliyetlerini karşılayamayan yeni bir dizi müşteri üretilir.

Dezavantajları:

• Kayıp Anlama - bir çerçevenin özelliklerine güvenerek bir geliştirici, işlerin nasıl çalıştığı konusunda (kaputun altında) anlayışı kaybetme tehlikesiyle karşı karşıyadır.
• Yapılandırma uçurum - çerçevenizin yapılandırmasından daha ileri gittiğinizde, üretkenliğiniz hemen düşer, özellikleri bir çerçeve yapılandırmasının dışında uygulamak zor olabilir.
• Geliştirici tramlines - siz (geliştirici) şeyleri geliştiricinin bir şeyler yapmasını istediği şekilde yapmanız gerekir.

İnsanların puanlarımda ne ifade ettiğini merak ediyorum ve kimse onlarla aynı fikirde değil mi? Ayrıca insanların ek puanları olursa minnettar olurum.

Sonuç olarak: bir çerçeve yapılandırmasının dışında özelliklerin uygulanması zor olabilir.

Bu varsayımı varsayımdan geçirelim.

Kayıp Anlayış - bir çerçevenin özelliklerine dayanarak, bir geliştirici, işlerin nasıl çalıştığı konusunda (kaputun altında) anlayışı kaybetme tehlikesiyle karşı karşıyadır.

Yanlış. İşlerin nasıl çalıştığını asla anlamayacaksınız. Çerçeveler büyülü değil. Bunlar sadece kendiniz yazmak zorunda olmadığınız kullanışlı kodlardır.

İster inanın ister inanmayın, çerçeveyi kullanarak hatalar yapacaksınız. Ne yaptığınızı anlamak için HTTP'nin en düşük düzeylerine kadar hata ayıklamanız gerekir.

Kaputun altında neler olup bittiğini asla kaybetmeyeceksin. Tabii ki, çerçeveniz o kadar destansı ve mükemmel değilse, asla bir sorununuz olmaz.

Yapılandırma uçurum - çerçevenizin yapılandırmasından daha ileri gittiğinizde, üretkenliğiniz hemen düşer, özellikleri bir çerçeve yapılandırmasının dışında uygulamak zor olabilir.

Bu çok az mantıklı.

İlk. Bir çerçevesiz bina, birim testi, hata ayıklama, tanılama, konfigürasyon kontrolü ve çerçevedeki diğer tüm değersiz işleri yeniden içeren geniş bir programlama görevine önemsiz bir iş yapabilir. Bu "verimlilik" nasıl?

İkinci. Çerçevenin dışında bir şeyler uygulamak her zaman çok iştir çünkü - ahem - bir çerçevenin dışında bir şey uygulamak her zaman çok iştir. Çerçeveyi öğrenmek ve yapılandırmak için harcanan zamanla hiçbir ilgisi yoktur. Çerçevenin dışında bir şey uygulamak doğal olarak zordur.

Geliştirici tramvayları - siz (geliştirici) işleri [çerçeve] geliştiricinin işleri yapmanızı istediği şekilde yapmanız gerekir.

Doğru. Ve bu genellikle iyi bir şeydir. İşleri tutarlı bir şekilde yapmak, kendi kişisel tercih yolunuzu yapmaktan daha değerlidir. “Öğrenme” ve “anlayış” gerektirebilir, ancak bunların değeri vardır.

Güvenlik sorunları - insanlara profesyonel görünümlü web sitelerini hızlı bir şekilde geliştirmek için bu araçları vermek potansiyel bir risktir, insanlar hileli şirketler için hızlı bir şekilde profesyonel görünümlü web siteleri oluşturabilir.

Ne? Bunun çerçeve ile ilgisi yok. Dolandırıcılık, kullanılan araçlara bakılmaksızın sahtekarlıktır.

Con: Olası olası düşüş / Popülerlik kaybı

• Temelde aynı şeyi yapan iki web çerçevesi varsa ve sizinki kazanmazsa, projenin ölme şansı vardır. Bu durumda, çerçeveyi kendiniz (açık kaynak) korumanız, uygulamayı yeniden yazmanız veya güncelleme yapmadan (kapalı kaynak) devam etmeniz gerekir.
• Çerçeveye bağlı olarak, başvurunuzu çerçevenin yayın takvimi ile yükseltmek zorunda kalabilirsiniz. Çok geride kalmak, destek için uygun olamayabilir. Hiçbir çerçeve olmadan, programınızda çalışabilirsiniz. (Bu, desteğe ihtiyacınız olup olmadığına bağlıdır).

Profesyonel: İşletmenin kodu

• Çerçeveler, homurdanma işi hakkında endişelenmenize izin vermez ve doğrudan işletmeye değer getiren koda odaklanır.
• Bazen (sadece çalışır) çerçeve yükseltmeleri kullanıcılarınıza pratik olarak "ücretsiz" olarak yeni özellikler sunmanıza izin verir. Özellikle özel kontrollerle gelen çerçevelerle (yeni sürümün bir tür arama / filtre sunabileceği bir ızgara gibi).

Avantajları

• Daha hızlı geliştirme süresi
• Daha az hata
• Daha hızlı paylaşılan geliştirme
• Kütüphane desteği
• Kolay DB etkileşimi

Dezavantajları

• Çerçeveye "Kutulu"
• Çekirdek davranışı genişletmek veya değiştirmek istediğinizde genellikle esnek değildir
• "Kıyamet Hataları" - kaynak veya temel mimariden kaynaklandıkları yerde iyi bir iz bırakmayan hatalar. Mükemmel bir örnek Grails kullanırken Spring hatalarıdır.

En basit projeler dışındaki herkes için çerçeveler kullanmayı savunuyorum. Mevcut bir HTML sitesine bir iletişim formu eklemeniz gerekiyorsa, bir çerçeveye geçmek yerine bir PHP dosyası kullanabilirsiniz.

Akla gelen birkaç şey ...

Avantajları

• Kodun yeniden kullanımı - bir çerçeve kullanarak, test edilmiş ve doğru olan kodu yeniden kullanıyorsunuzdur.
• Hızlı geliştirme / prototip oluşturma.
• güvenli olduğu varsayılabilen (genellikle) entegre giriş doğrulaması (geliştiricinin doğru şekilde kullandığı göz önüne alındığında)

Dezavantajları

• Destek kaybı. Burada akla gelen Symfony 1.4. Symfony'un 1.4'ü oldukça uzun bir süre destekleyeceğini düşünüyorum, ancak 2.0'ın geriye dönük uyumlu olmadığını bilerek 1.4, önümüzdeki yıllarda bir destek çıkmazı gibi görünüyor.
• Üstten; Bir çerçeve kullanarak, özel uygulamanız için geçerli olmayan ancak başkaları için geçerli olan binlerce satır çalıştırıyorsunuz. Bazıları bunu makul bir takas olarak görür ve bazıları performans için kodlarını sıfırdan yazmayı tercih eder.
• Özel ihtiyaçlarınız için yanlış çerçeveyi kullanmak. Tüm çerçeveler eşit olarak oluşturulmaz.

Her şey kullandığınız çerçeveye bağlıdır.

ASP.NET kullanıyorsanız, bir dezavantajınız vardır: En iyi ihtimalle sızdıran bir soyutlamadır ve en kötüsü , diğer çerçevelerde önemsiz olan şeyleri gizlememeniz için acı çekiyor Web üzerinde çalışıyor.

ASP.NET MVC bu sorunu düzeltmek istiyor ve çok iyi yapıyor.

İşler yapmak için daha fazla zaman ve iskele oluşturmak için daha az zaman harcayabilmemiz için çerçeveler mevcuttur. Bu bağlamda, iskele kurmak için gerçekten zaman harcamak istemiyorsanız, herhangi bir dezavantaj görmüyorum.

Bazı noktalar eklemek istiyorum.

• Bulduğum çerçevelerle ilgili en büyük sorunlardan biri insanların düşünmeyi bırakması. Sadece çerçeveyi kullanmak istiyorlar çünkü havalı veya her zaman çerçeveyi kullanıyorlar. Kullanımın haklı olup olmadığını düşünmek için durmuyorlar.
• Lisanslama, insanlar gerçekten lisanslamaya bakmadan çerçeveleri kullanıyor gibi görünüyor. Bunun farkında olmadıkları anlamına gelebilir. Veya lisans değiştiğinde ne olacağını düşünün.
• Aynı tür çerçevelerin çoğunu kullanmak. Bazen, aslında hemen hemen aynı şeyi yapan birçok çerçeve olabilir. Bir şirket olarak eğitimli seçimler yaparsınız ve her proje için farklı bir çerçeveye sahip olmazsınız.
• Yeni sürümlere ayak uydurmak zor olabilir

Yine de, avantajları göz önüne aldığınızda, çerçeveleri değerlendirmek, lisansları değerlendirmek, kullanım başına çerçevelerin temiz bir listesini tutmak ve akıllı bir versiyonlama stratejisine sahip olmak için biraz daha fazla çaba harcamayı düşünüyorum.

Avantajları:

• sürekli olarak çerçeveler kullandığınızda, projeleriniz üzerinde çalışmış olan insanlar için projelerin öğrenme süresi azalır.
• kendi daha hızlı gelişimin
• kendi güçlendirici geliştiricileriniz

Son 13 yılda kişisel deneyimimden bahsediyorum. Şirketimde dikmeler kullandık, kısa bir eğriden sonra harikaydı. Bir sonraki projemde çoğunlukla opak, biraz dikenli ama büyümüş bir mimari kullandık, onu genişletebilirdik ama çekirdek kodu sadece kavanozlardı. Ve bunun gibi. son 3 yılda küçük bir şirkette çalışıyor (dev <30 sayısı) ve hepsi kendi jsps, sunucu ve ejbs idi. Birden fazla müşterimize ve jsps tekrarı incelendiğinde, 2012 yılında payandaların% 20'sini taklit eden bir j2ee filtresi yapmaktı. Neden stuts 2 kullanılmıyor? Keşke sahip olsaydık ama: baş mimarımızı geçemedi; yeterli deneyim veya zaman yok.

Mini çerçevemizin kullandığı bazı ortak jsps'leri durdurduk. Şimdi bir struts 2 kitap aracılığıyla gitmek için zaman oldu zaman biz çok özledim görmek!

Bazı harika algoritmalar ve önbellekler ve kullanıcı arayüzü kullanıyoruz, ancak çok fazla saat kaybettik ve emekliye ayrılmak için 3 yıllık bir planımız olan çok fazla kodla yükümlü.