Java Server Faces 2.0'in ana dezavantajları nelerdir?
dün Java Server Faces 2.0'da gerçekten etkileyici görünen bir sunum gördüm, şu anda mutlu olduğum halde ASP.NET MVC / jQuery geliştirici. JSF hakkında en çok sevdiğim şey, geliştirmeyi çok daha hızlı hale getiren AJAX özellikli UI bileşenlerinin büyük miktarıydı ASP.NET MVC, özellikle AJAX-ağır sitelerde. Entegrasyon testi de çok güzel görünüyordu.
sunum sadece jsf'nin avantajlarını vurguladığından, duymak isterim diğer tarafta da.
yani sorularım:
- java Server Faces 2.0'in ana dezavantajları nelerdir?
- bir JSF geliştiricisinin kullanmayı düşünmesi ne olabilir ASP.NET JSF yerine MVC?
13 ответов
JSF 2.0 dezavantajları? Dürüst olmak gerekirse, temel Web geliştirme (HTML/CSS/JS, sunucu tarafı karşı istemci tarafı, vb) ve temel Java Servlet API (istek/yanıt/oturum, yönlendirme/yönlendirme, vb) hakkında sağlam bir arka plan bilgisi olmadığında göreceli dik öğrenme eğrisi dışında ciddi dezavantajlar akla geliyor. JSF mevcut sürümde hala sırasında kazanılan olumsuz görüntü kurtulmak gerekiyor erken yaşlarda, birkaç ciddi dezavantaj vardı.
JSF 1.0 (Mart 2004)
bu ilk sürümdü. Bu konuda bilmek istemiyorum çekirdek ve performans alanlarında hem de hatalar ile darmadağın oldu. Webapplication'ınız sezgisel olarak beklediğiniz gibi her zaman çalışmadı. Sen de ağlamaktan çok uzak duracaktın.
JSF 1.1 (Mayıs 2004)
bu bugfix sürümüdür. Bu performans hala çok gelişmiş değildi. Ayrıca büyük bir dezavantaj vardı: JSF sayfasında HTML'yi kusursuz bir şekilde sıralayamazsınız. Tüm düz vanilya HTML önce JSF bileşen ağacı elde. Tüm düz etiketleri
<f:verbatim> etiketlerine sarmanız gerekir, böylece JSF bileşen ağacına dahil olurlar. Bu şartname uyarınca olmasına rağmen, bu çok eleştiri aldı. Ayrıca Bkz. a.o. JSF / Facelets: neden karıştırmak iyi bir fikir değil mi HTML etiketleri ile JSF/Facelets?
JSF 1.2 (Mayıs 2006)
bu Ryan Lubke tarafından yönetilen yeni JSF geliştirme ekibinin ilk sürümüdür. Bir şey düzgün çalışmıyor ve ne olduğundan emin değiliz. Spec'de de değişiklikler vardı. Büyük değişiklik, görünüm işleme iyileştirilmesi oldu. Bu sadece jsf'yi JSP'DEN tamamen ayırmakla kalmaz, bu nedenle JSP'DEN farklı bir görünüm teknolojisi kullanabilir, ancak geliştiricilerin HTML'de satır içi düz görünümlere izin verir
<f:verbatim> etiketleri ile uğraşmadan JSF sayfası. Yeni takımın bir diğer önemli odak performansı artırıyordu. Sun JSF referans uygulama 1.2 ömrü boyunca (kod adı verilen mojarra inşa beri 1.2_08, etrafında 2008), hemen hemen her yapı ile sevk var (major) her zamanki yanında performans iyileştirmeleri (minor) onarımları.
JSF 1'in tek ciddi dezavantajı.x (1.2 dahil) bir kapsam eksikliği olduğunu isteği ve oturumu kapsamı arasında konuşma kapsamı. Bu, geliştiricileri, daha karmaşık webapplications'ta doğrulamaları, dönüşümleri, model değişikliklerini ve eylem çağrılarını başarıyla işlemek için sonraki istekte ilk model verilerini korumak istediğinizde, gizli giriş öğeleri, gereksiz DB sorguları ve/veya Oturum kapsamını kötüye kullanmaya zorladı. Acı olabilir MyFaces Tomahawk
<t:saveState> bileşeni, JBoss Seam konuşma kapsamı ve MyFaces Orchestra konuşma çerçevesi gibi sonraki istekte gerekli verileri koruyan bir 3. parti Kütüphanesi benimseyerek yumuşatılabilir.
HTML/CSS purists için başka bir dezavantaj, JSF'NİN HTML öğesinin benzersizliğini sağlamak için ID ayırıcı karakteri olarak
: kolonunu kullanmasıdır Oluşturulan HTML çıktısında
id , özellikle bir bileşen görünümünde birden fazla kez yeniden kullanıldığında (templating, iterating components, vb.). Bu, CSS tanımlayıcılarında yasadışı bir karakter olduğundan, CSS seçicilerinde kolondan kaçmak için
\ kullanmanız gerekir; bu da
#formId\:fieldId {} veya
#formIdA fieldId {} gibi çirkin ve garip görünümlü seçicilerle sonuçlanır . Ayrıca Bkz. colon ile JSF oluşturulan HTML öğesi kimliği nasıl kullanılır ":" CSS seçicilerinde? Ancak, eğer siz bir purist değilsiniz, varsayılan olarak de okuyun, JSF, web standartlarının bir parçası ile uyumlu olmayan kullanılamaz kimlikler üretir .
ayrıca, JSF 1.x kutudan Ajax tesisleri ile gemi vermedi. Gerçekten teknik bir dezavantaj değil, ancak bu dönemde web 2.0 yutturmaca nedeniyle işlevsel bir dezavantaj haline geldi. Exadel , yıllar boyunca iyice geliştirilen ve Ajax4jsf'yi tanıtmak için erken oldu çekirdek parçası Jboss RichFaces bileşen kütüphanesi. Başka bir bileşen kütüphaneleri de yerleşik güçleri ile sevk edildi, iyi bilinen bir İCEfaces olmak .
yaklaşık yarım JSF 1.2 ömrü, yeni bir XML tabanlı görünüm teknolojisi tanıtıldı: Facelets . Bu özellikle templating alanında, JSP yukarıda büyük avantajlar sundu.
JSF 2.0 (Haziran 2009)
bu ikinci büyük sürüm oldu, buzzword olarak Ajax ile. Birçok teknik ve fonksiyonel değişiklik vardı. JSP varsayılan görünüm teknolojisi ve Faselets saf XML ( kompozit bileşenler olarak adlandırılan) kullanarak özel bileşenler oluşturmak için yetenekleri ile genişletildi olarak Faselets ile değiştirilir. Ayrıca Bkz: neden Jsf2 görünüm tanımı dili olarak JSP üzerinde Faselets tercih edilir.0'dan sonra mı?
Ajax güçleri Ajax4jsf ile çok benzerlikler vardır
<f:ajax> bileşeninin lezzet tanıtıldı. Açıklamalar ve kongre-over-yapılandırma geliştirmeleri ve ayrıntılı
faces-config.xml dosyasına mümkün olduğunca tanıtıldı. Ayrıca, varsayılan adlandırma kapsayıcı kimliği ayırıcı karakteri
: yapılandırılabilir hale geldi, böylece HTML/CSS temizleyicileri rahatlamış olabilir. Yapmanız gereken tek şey
web.xml
init-param olarak tanımlamaktır
javax.faces.SEPARATOR_CHAR adıyla ve
- gibi istemci kimliğinin herhangi bir yerinde karakteri kendiniz kullanmadığınızdan emin olun.
son ama en az değil, yeni bir kapsam tanıtıldı, görünüm kapsamı. Başka bir büyük JSF 1 elimine etti.x dezavantaj daha önce açıklandığı gibi. Sadece
@ViewScoped fasulyesini, sonraki (konuşma) isteklerinde verileri korumanın tüm yollarını sorunsuz bir şekilde konuşma kapsamını etkinleştirmek için beyan edersiniz. Bir
@ViewScoped fasulye, daha sonra aynı görünüme (açılan tarayıcı sekmesinden/penceresinden bağımsız olarak) gönderdiğiniz ve gezindiğiniz sürece yaşayacaktır!), zaman uyumlu veya zaman uyumsuz (Ajax). Ayrıca Bkz. yönetilen fasulyelerde görünüm ve istek kapsamı arasındaki fark ve doğru fasulye kapsamını nasıl seçebilirim?
JSF 1'in hemen hemen tüm dezavantajlarına rağmen.x elendi, JSF 2.0 spesifik hatalar var gösteri ustası olabilir.
@ViewScoped etiketi işleyicileri başarısız nedeniyle kısmi devlet tasarrufu bir tavuk yumurtası sorunu. Bu JSF 2.2 ve mojarra 2.1.18 backported sabittir. Ayrıca HTML5
data-xxx gibi özel öznitelikler geçen desteklenmez. Bu, yeni passthrough öğeleri/öznitelikler özelliği ile JSF 2.2'de sabitlenir. Ayrıca JSF uygulama Mojarra sorunları kendi kümesi vardır . Nispeten birçoğu, ,
<ui:repeat> , yeni kısmi durum tasarruf uygulaması ve kötü uygulanan flaş kapsamı . Çoğu 2.2 Mojarra giderilmiştir.x versiyonu.
JSF 2.0 süresi etrafında, PrimeFaces jQuery ve jQuery UI dayalı tanıtıldı. En popüler JSF bileşen kütüphanesi oldu.
JSF 2.2 (Mayıs 2013)
, JSF 2.2'nin piyasaya Sürülmesiyle, HTML5, teknik olarak tüm eski JSF sürümlerinde desteklenmesine rağmen buzzword olarak kullanıldı. Ayrıca Bkz. JavaServer 2.2 ve HTML5 desteği ile karşı karşıyadır, neden XHTML hala kullanılıyor . En önemli yeni JSF 2.2 özelliği, özel tableless radyo düğmesi gibi bir olasılık dünyasını açarak özel bileşen öznitelikleri için destektir gruplar .
, belirli hataların ve bir doğrulayıcı/dönüştürücüye EJB enjekte edememe (zaten JSF 2.3'de düzeltildi) gibi bazı "can sıkıcı küçük şeylerin yanı sıra, JSF 2.2 spesifikasyonunda gerçekten büyük dezavantajlar yoktur.
bileşen tabanlı MVC vs istek tabanlı MVC
bazı JSF büyük dezavantajı üzerinde çok az ince taneli kontrol sağlar olduğunu tercih edebilir oluşturulan HTML / CSS / JS. Bu jsf'nin kendi değil, çünkü bileşen tabanlı MVC çerçevesi değil, istek (eylem) tabanlı MVC çerçevesi. Bir MVC çerçevesi göz önüne alındığında, HTML/CSS/JS kontrol yüksek derecede büyük bir gereklilik ise, o zaman zaten bir bileşen tabanlı MVC framework bakarak olmamalı, ancak Bahar MVC gibi bir istek tabanlı MVC framework. Sadece içine almak gerekir tüm bu HTML/CSS/JS boilerplate kendiniz yazmak zorunda kalacağınızı hesaplayın. Ayrıca Bkz. istek MVC ve bileşen MVC arasındaki fark .
Ayrıca bakınız:
- JSF, Servlet ve JSP arasındaki fark nedir? (sadece temellerini anlamak için)
- tableless CSS düzenleri geliştirmek için JSF kullanarak (JSF hakkında başka bir efsane)
- JSF vs düz HTML/CSS / JS / jQuery (JSF yanlış seçim olduğunda)
- web uygulamalarında tasarım desenleri (MVC arkasındaki ideolojiyi göstermektedir)
JSF ile 5 yıl çalıştıktan sonra, 2 sent ekleyebileceğimi düşünüyorum.
iki büyük JSF .:
- büyük öğrenme eğrisi. JSF karmaşıktır, bu sadece doğrudur.
- onun bileşeni doğa. Bileşen tabanlı çerçeve, Web'in gerçek doğasını gizlemeye çalışır; bu, çok miktarda komplikasyon ve felaket ile birlikte gelir (jsf'ye girmemek gibi yaklaşık 5 yıl içinde).
geliştiriciden HTTP isteği/yanıtı gizleyen IMHO büyük bir hatadır. Deneyimimden, her bileşen tabanlı çerçeve web gelişimine soyutlama ekler ve bu soyutlama gereksiz yükü ve daha yüksek karmaşıklığı ile sonuçlanır.
ve minor akla gelen sakıncaları:
- nesnenin varsayılan kimliği, ebeveynlerin kimlikleri, örneğin form1: button1.
- yanlış sayfanın parçasını yorumlamak için kolay bir yol yok. Etiket
<ui:remove>zaten ayrıştırılır sözdizimsel olarak doğru içeriğe ihtiyacı var.
- devam etmeden önce
isRendered()yöntemini kontrol etmeyen düşük kaliteli 3.taraf bileşenleri.
- ' daha az ve Sencha zor.
- dinlenme ile iyi oynamıyor.
- UX tasarımcıları için o kadar kolay değil, çünkü hazır bileşenlerin üzerine yazılması gereken kendi CSS stilleri var.
beni yanlış anlama. Sürüm 2'de bir bileşen çerçevesi JSF gerçekten iyi, ama yine de bileşen tabanlı ve her zaman olacak...
goblen, Wicket ve deneyimli JSF geliştiricilerin düşük coşku düşük popülerlik bir göz atın (daha da anlamlı ne). Ve kontrast için, al raylar, Grails, Django, oyun başarısı bir göz! Çerçeve-hepsi eylem tabanlı ve programcı gerçek istek/yanıt ve vatansız doğa web gizlemek için çalışmayın.
benim için büyük JSF dezavantajı. IMHO JSF, bazı tür uygulamalara (intranet, formlar yoğun) uygun olabilir, ancak gerçek hayat için web uygulaması gitmek için iyi bir yol değildir.
umut bu ön uç ile ilgili kendi seçimleri ile birine yardımcı olur.
akla gelen birkaç dezavantaj:
- JSF bileşen tabanlı bir çerçevedir. Bu doğal kısıtlamalar vardır itaat ile ilgisi var bileşen modeli.
- AFAIK JSF sadece gönderiyi destekliyor, bu yüzden bir yere sahip olmak istiyorsanız düz bir servlet/JSP yapmak.
- çoğu bileşen, etki alanları üzerinde soyutlamalar sağlamaya çalışır ilişkisel veritabanları ve ön uç JavaScript ve birçok kez bunlar soyutlama "sızdıran" ve hata ayıklamak çok zor.
- Bu soyutlamalar genç bir geliştirici ya da (örneğin, ön-JavaScript sonu) belirli bir etki alanı ile rahat biri için iyi bir başlangıç noktası olabilir, ama kaputun altında neler olduğunu biraz anlayış var, bunları kullanan ilgili birkaç kat, ve çoğu insan olduğundan performans için optimize etmek çok zor.
- genellikle JSF ile kullanılan templating mekanizmalarının hiçbir ilgisi yoktur web tasarımcıları nasıl çalışır. JSF için WYSIWYG editörleri ilkel ve her durumda, tasarımcınız size dönüştürme için harcamak zorunda kalacağınız HTML / CSS verecektir.
- el ifadeleri gibi şeyler statik olarak kontrol edilmez ve hem derleyici hem de Ide'ler hataları bulmada iyi bir iş çıkarmaz, bu nedenle çalışma zamanında yakalamak zorunda kalacağınız hatalarla sonuçlanırsınız. Bu, Ruby veya PHP gibi dinamik olarak yazılan dil için iyi olabilir, ancak buna dayanmak zorunda kalırsam Java ekosisteminin şişmesi, şablonlarım için yazmayı talep ediyorum.
özetlemek için: JSF ile kaydedeceğiniz zaman, JSP/servlet/bean boilerplate kodunu yazmaktan kaçınarak, ölçeklendirip tam olarak ne yapmak istediğinizi yapmak için x10 harcarsınız.
bana JSF 2.0'ın en büyük dezavantajı, yalnızca jsf'nin değil, aynı zamanda yararlı işler yapmak için kullanmak zorunda olduğunuz bileşen kütüphanelerinin de öğrenme eğrisidir.: gerçekten yetkin olmak ile uğraşmak zorunda özellikleri ve standartları şaşırtıcı sayıda düşünün
- çeşitli enkarnasyonlarda HTML. Bilmene gerek yok gibi davranma.
- HTTP - neler olup bittiğini anlayamadığınızda Firebug'u aç ve gör. Bunun için bunu bilmelisin.
- CSS -- Beğen ya da beğenme. Bir şey düzgün çalışmıyor ve ne olduğundan emin değiliz.
- XML -- JSF muhtemelen ad alanlarını bu dereceye kadar kullandığınız ilk yer olacaktır.
- Servlet Özellikleri. Er ya da geç bu pakette arama yöntemlerine gireceksiniz. Bunun dışında, Faseletlerinizin XHTML'YE nasıl dönüştüğünü bilmek Zorundasınız.
- JSP (çoğunlukla neden JSF'YE ihtiyacınız olmadığını biliyorsunuz)
- jstl (yine, çoğunlukla eski çerçeve ile başa çıkmak için)
- ifade Dili (EL) çeşitli biçimlerde.
- ECMAScript, JavaScript, ya da başka ne aramak istiyorsanız.
- JSON -- kullanmasanız bile bunu bilmelisiniz.
- AJAX. JSF 2.0, bunu sizden saklamanın iyi bir işi olduğunu söyleyebilirim, ancak yine de ihtiyacınız var neler olduğunu bilmek.
- DOM. Ve bir tarayıcı nasıl kullanır. Bakın ECMA.
- DOM olayları-tek başına bir konu.
- Java Kalıcılık mimarisi (JPA), uygulamanızın herhangi bir arka uç veri tabanına sahip olmasını istiyorsanız.
- Java kendisi.
- JSEE siz buradayken.
- bağlam bağımlılık enjeksiyon belirtimi (CDI) ve nasıl ile çatışır ve JSF 2.0 ile kullanılır
- JQuery -- onsuz anlaşmanı görmek istiyorum.
şimdi, bir kez sen-ebilmek almak on tescilli özellikleri, yani bileşen kütüphaneleri ve sağlayıcı kütüphaneleri ile yapılır yol boyunca pick up:
- PrimeFaces (seçim benim bileşen kütüphanesi)
- RichFaces
- MyFaces
- Icefaces
- EclipseLink (benim JPA sağlayıcı)
- Hibernate
- kaynak
ve kabı unutma! Ve tüm bu yapılandırma dosyaları:
- GlassFish (2, 3, vb.)
- JBoss
- Tomcat
yani -- bu kolaylaştırıyor? Elbette, JSF 2.0, yapmak istediğiniz tek şey olduğu sürece "kolay" en basit etkileşimlere sahip en temel web sayfaları.
basitçe söylemek gerekirse, JSF 2.0 bugün yazılım evreninde olduğu gibi yapıştırılmış teknolojilerin en karmaşık ve hantal mishmash olduğunu. Ve kullanmayı tercih ettiğim bir şey düşünemiyorum.
- deneyimsiz geliştiriciler genellikle acı yavaş ve kod gerçekten çirkin ve bakımı zor olacak uygulamaları yaratacak. Onun aldatıcı başlatmak için basit, ama aslında iyi programlar yazmak istiyorsanız öğrenme bazı yatırım gerektirir.
- en azından başlangıçta sık sık bazı problemlerde "sıkışmış" olacaksınız ve internette aslında çalışmaktan daha fazla balusc mesajları okumak için daha fazla zaman harcayacaksınız:) bir süre sonra daha az ve daha az olacaktır, ama yine de can sıkıcı olabilir.
- sorunun bilgi / hata eksikliği ama aslında bir hata nedeniyle olmadığını öğrendiğinizde daha da sinir bozucu. Mojarra oldu (nedir?) oldukça buggy ve bileşenlerin başka bir katman daha fazla sorun ekler. Richfaces şimdiye kadar yazılmış en büyük bok yazılımıydı:) sürüm 4'te nasıl olduğunu bilmiyorum. Biz daha iyi olan Primefaces var, ama yine de özellikle daha egzotik bileşenleri ile hata veya özellik eksikliği içine çalışacaktır. Ve şimdi Primefaces güncellemeleri için ödeme yapmanız gerekecek. Bu yüzden arabasını söyleyebilirim, ancak özellikle 2.2 sürümü spec ile ilgili bazı sorunları düzelttikten sonra daha iyi hale geliyor. Çerçeve daha olgun ama yine de mükemmel olmaktan uzak (belki de daha iyi mi?).
- özellikle esnek bulamıyorum. Genellikle çok özel bir şeye ihtiyacınız varsa ve bunu yapan herhangi bir bileşen yoksa-biraz acı verici olacaktır. Yine ortalama geliştirici perspektifinden bahsediyorum-son tarihleri olan, hızlı okuma eğitimleri ve gerçekten işe yarıyor :) öğrenmek için hiçbir zaman sık Sık bazı bileşenler "hemen hemen" ne gerek, ama bazen istediğin bir şeyin gerçekleşmesi için çok fazla zaman harcamak olmayabilir tam olarak :) kendi ya da işkence varolan bileşen oluşturmak için daha iyi bir değerlendirirken dikkatli olmak Gerekir gibi görünüyor çünkü sıkışmış zaman stackoverflow arama. Aslında gerçekten benzersiz bir şey yaratıyorsanız, JSF'Yİ tavsiye etmem.
so ın kısa benim dezavantajları olurdu: karmaşıklık, çok düzgün gelişme ilerleme değil, buggy, esnek olmayan.
tabii ki de avantajlar var, ancak sorduğunuz şey bu değil. Her neyse, başkalarının farklı görüşlere sahip olabileceği deneyimim, bu yüzden en iyi yol, sizin için olup olmadığını görmek için bir süre denemektir (sadece daha karmaşık bir şey - naif örnekler değil-JSF gerçekten orada parlar:) IMHO JSF için en iyi kullanım durumu CRMs vb.gibi iş uygulamaları...
"JSF, denetleyici koduna girmeden kontrol edemeyeceğiniz veya değiştiremeyeceğiniz Görünüm katmanı HTML ve JavaScript üretecektir."
aslında JSF size esneklik sağlar, standart/üçüncü taraf bileşenleri kullanabilir veya işlenen şey üzerinde tam kontrole sahip olan kendi oluşturabilirsiniz. JSF 2.0 ile özel bileşenlerinizi oluşturmanız gereken tek bir xhtml.
JSF ile örnek bir proje geliştirdik (üç haftalık bir araştırmadı, bu yüzden bazı şeyleri kaybedebiliriz!)
çekirdek jsf'yi kullanmaya çalışıyoruz, eğer bir bileşen gerekiyorsa PrimeFaces kullandık.
proje navigasyon ile bir web sitesi oldu. Menü tıklandığında her sayfa ajax aracılığıyla yüklenmelidir.
site iki usecases vardır:
- ızgaralı bir sayfa. Izgara ajax ile yüklenir ve 1519110920 sıralama ve çağrı destek''
- üç adımlı sihirbaz sayfası. Her sayfanın istemci tarafı doğrulaması (basit doğrulamalar için) ve sunucu tarafı ajax taban doğrulaması (karmaşık doğrulamalar için) vardır. Herhangi bir sunucu özel durumu ( hizmet katmanından) sihirbazın aynı sayfasında bir sonraki sayfaya gitmeden görüntülenmelidir.
bunu bulduk:
- JSF görünümünü yapmak için omniFaces bazı kesmek kullanmanız gerekir durum düzeltildi. JSF durumu, ajax aracılığıyla sayfaları birbirine eklediğinizde bozulur. Bu, JSF'DE bir hata gibi görünüyor ve bir sonraki sürümlerde (2.3'de değil) düzeltilebilir.
- JSF akışı ajax ile doğru çalışmıyor (ya da işe yaramadık!) Bunun yerine primeface Sihirbazı bileşenini kullanmaya çalışıyoruz, ancak istemci doğrulaması desteklenmiyor ve standart JSF akış standardı olmasa da ortalama görünüyor.
- jqgird gibi bazı jQuery bileşenlerini kullanırken, ve JSON sonuçlarını yüklemeniz gerekir, o zaman saf servlet kullanmanız önerilir, JSF sizin için hiçbir şey yapmaz. Bu tür bileşenleri kullanırsanız, tasarımınız JSF'YE uymaz.
ajaxCompleteajax
ajaxCompletetarafından tamamlandığında bazı istemci komut dosyalarını yapmaya çalışıyoruz ve PF 4'ün kendi ajax olaylarını uyguladığını bulduk. Bazı jQuery bileşenlerimiz vardı ve kodlarını değiştirmeliyiz.
yukarıdaki örneği olarak değiştirirseniz Ajax olmayan projesi (veya en azından daha az ajax projesi) yukarıdaki sorunların çoğunu karşı karşıya kalmazsınız.
araştırmamızı şöyle özetliyoruz:
JSF tam ajax baz web sitesinde iyi çalışmıyor.
tabii ki bazı projelerde çok yararlı olabilir JSF güzel özellikleri bir sürü bulmak, bu yüzden proje ihtiyaçlarını düşünün.
lütfen JSF teknik belgelerine bakın inceleme JSF avantajları ve bence JSF en büyük avantajı, @BalusC tam ve büyük destek; -)
ben bir Java sunucusu değilim ve hiç uzman değilim. Ama IMHO ana dezavantajı sunucu tarafı olmasıdır. Sunucu tarafı web Sunum Katmanı çerçevelerini öğrenmekten ve kullanmaktan yoruldum. ASP.NET Web formları, ASP.NET MVC, Java Server Faces, Struts, php frameworks ve Ruby on rails frameworks. Hepsine elveda dedim ve Angularjs ve Typescript'e Merhaba dedim. Sunum katmanım tarayıcıda çalışır. Php çalıştıran Windows IIS tarafından sunulup sunulmadığı önemli değil veya ASP.NET ya da eğer Linux üzerinde çalışan bir Apache Web sunucusu tarafından sunulmaktadır. Sadece her yerde çalışan tek bir çerçeve öğrenmem gerekiyor.
sadece benim iki sent.
benim için jsf'nin en büyük dezavantajı, programlı (dinamik olarak) oluşturulan sayfalar için zayıf bir destektir.
Sayfanızı (sayfa bileşeni modeli oluşturma) java kodundan dinamik olarak oluşturmak istiyorsanız. Örneğin WYSIWYG web sayfası Oluşturucusu üzerinde çalışıyorsanız. Bu kullanım durumunun yeterli dokümantasyonu genellikle mevcut değildir. Denemeniz gereken birçok nokta vardır ve gelişme yavaştır. Birçok şey sadece nasıl işe yaramaz beklemek. Ama genellikle onun olası bir şekilde kesmek.
İyi olan şey, jsf'nin felsefesinde veya mimarisinde sorun değil. Sadece yeterince özenli değil (bildiğim kadarıyla).
JSF 2, bileşen geliştirmeyi kolaylaştırması gereken Kompozit bileşenleri getirdi, ancak dinamik (programlı) yapı desteği çok zayıf. Dinamik Kompozit bileşen yapımının karmaşık ve neredeyse belgesiz sürecini aşarsanız, birkaç Kompozit bileşeni biraz daha derine sokarsanız, çalışmayı bıraktıklarını, bazı istisnalar attığını öğreneceksiniz.
ancak JSF topluluğunun bu eksikliklerin farkında olduğu görülüyor. Bu iki hatadan görebileceğiniz gibi bu konuda çalışıyorlar
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599
durumu en azından belirtimden bahsediyorsak JSF 2.2 ile daha iyi olmalıdır.
son birkaç aylık Primefaces/JSF deneyimimi yorumladı:
- bileşenleri "raftan" kullanırsanız, sanırım korkunç değil.
- ancak, dışarı çıkıp özel Uı'lere ihtiyaç duyduğunuzda iyi oynamaz. - Örneğin, projemiz için Twitter'ın bootstrap'ı kullanmamız gerekiyordu. (Değil primefaces bootstrap).
- şimdi sayfalarımız aşağıdaki gibi çalışır:
- sayfa yükler.
- kullanıcı ajax işlevselliği olan bir Primefaces ile etkileşime girer
- Bootstrap javascript bağlamaları
- her şeyi geri almak için ekstra javascript çalıştırıyoruz
- şimdi sayfalarımız aşağıdaki gibi çalışır:
JavaScript yazmaktan kaçınmak için jsf'nin sözü, Primefaces kullanmasaydıklarımızdan daha fazla javascript yazmaya dönüştü-ve bu javascript, primefaces'ı düzeltmektir kırılıyor.
bir zaman lavabosu-bir daha "raftan" şeyler kullanmadığınız sürece. Selenyum ile çalışmak zorunda kalırken de gerçekten çirkin (Primefaces). Her şey yapılabilir-ama yine de-sadece çok zaman var.
bir UX/tasarım ekibi ile çalışıyorsanız ve UI üzerinde hızlı bir şekilde yinelemeniz gerekiyorsa bunu kesinlikle kaçının-jquery/writing straight HTML-veya react/angular'a bakarak öğrenerek zamandan tasarruf edebilirsiniz.
JSF birçok avantajı vardır, bu yüzden dezavantaj olmak üzerine birkaç puan eklememe izin verir.
bir zaman diliminde bir Web projesi uygulama pratik bir senaryo üzerinde aşağıdaki faktörlere bir göz tutmak gerekir.
- takımınızda en iyisini önerebilecek kadar üst düzey üyeniz var mı her senaryo için uygun kontroller?
-
ilkini karşılamak için bant genişliğine sahip misiniz öğrenme eğrisi?
-
EKİBİNİZDE JSF
yi inceleyebilecek yeterli uzmanlığa sahip misiniz geliştiriciler tarafından üretilen şeyler?
cevabınız sorular için 'hayır' ise, sürdürülebilir olmayan bir kod tabanında sona erebilir.