Çeşitli Java web çerçevelerinin artıları ve eksileri nelerdir? [kapalı]


85

Java kullanarak kendi web sitemi oluşturmayı düşünüyorum ve hangi çerçeveyi kullanacağıma karar vermeye çalışıyorum. Bununla birlikte, Java çerçeveleri için hızlı bir arama yapmak, aralarından seçim yapabileceğiniz 50'den fazla döndürür!

Web sitem başlangıçta kendi zevkime göre olacak, ancak popüler hale gelirse, biraz ölçeklenebilir olması veya en azından bunun için yeniden tasarlayabilmesi için iyi olur.

Daha popüler çerçeveler arasındaki temel farklar nelerdir? Birinin diğerlerinden önemli ölçüde daha iyi performans gösterdiği durumlar var mı? Örneğin, yüksek trafikli kurumsal uygulamalara karşı düşük trafikli küçük uygulamalar. Bazılarının öğrenmesi ve kullanması diğerlerinden çok daha kolay olup olmadığını da merak ediyorum.

Bu çerçevelerin bazılarıyla ilgili deneyime sahip olan ve bir tavsiyede bulunabilecek biri var mı? Çok sayıda seçenek, mümkün olduğunda Java tabanlı web geliştirmeden kaçınmak için bir erken uyarı işlevi görüyor mu?


Bir dereceye kadar, bu, "hızlı bir alet araması yapmak 50'den fazla alet döndürür; bir çekiç, tornavida veya pense seçmeli miyim?" Demek gibidir. Yine de, alt sorularla, bu iyi bir "iyi öznel" sorudur.
Pops

Her zamanki gibi "komik", son derece faydalı sorular ve cevaplar (Wicket hakkında kitap sipariş ettim, hepinize teşekkür ederim), ancak yazının tamamı yapıcı olmadığı için kapalı. "bu soru OLASI" - ve bu kuru gerçek, spekülatif hiçbir şey, ah ironi ...
greenoldman

Yanıtlar:


59

Ben kullandım Goblen 3 , Wicket , Echo ve JSF oldukça yaygın. Bunlara bir göz atmanızı ve sizin için en kolay görünen ve çalışmayı tercih ettiğiniz yönteme en yakın olanı seçmenizi gerçekten tavsiye ederim.

Bunların, birlikte çalışmak için benim için en rahat Wicket nedeniyle bileşen bina ve sayfa çiftleşmiş basitliği hafif yapısı nedeniyle,. Hibernate veya başka bir çerçeve yerine kendi db kodunuzu kullanıyorsanız (Wicket Hibernate veya Spring Integration'dan hiçbir zaman tamamen memnun olmadım) bu iki katına çıkar.

Tüm mizanpajınızı Java'da yazmanın sakıncası yoksa Echo harikadır. Bunun şimdi farklı olduğunu biliyorum, ancak yine de bu ürünün oldukça dar bir alana hizmet ettiğini düşünüyorum. Göründüğü gibi her büyük sürümde geliştirme modelini değiştiriyorlar.

Goblen harika bir ürün, ancak esas olarak tek bir adam tarafından yönetildiği için geliştirme modeli açısından diğerlerinden açıkça farklı. Howard Lewis Ship şüphesiz oldukça akıllı, ancak her sürümle geriye dönük uyumluluğu temelde unutmaya karar vermelerinden hayal kırıklığına uğradım. Yine de, ihtiyaçlarınız için bu önemli olmayabilir ve Goblen ürünlerini her zaman karşı çalışmak için zevkli buldum.

JSF yıllardır dışarıda ve hala bir Struts elemanının Struts'ın tüm sorunlarını çözmek için yaptığı bir şey gibi hissediyor . Struts ile ilgili tüm sorunları gerçekten anlamadan. Ürün açıkça çok esnek olmasına rağmen, hala bitmemiş bir hissi var. Onu kullanıyorum ve ona biraz düşkünüm, geleceği için büyük umutlar besliyorum. Bence JEE6'da sunulacak bir sonraki sürüm (2.0), yeni bir şablon sözdizimi (Facelets'e benzer) ve basitleştirilmiş bir bileşen modeli (yalnızca 1 dosyada özel bileşenler ... son olarak) ile onu gerçekten kendi haline getirecek.

Ve tabii ki, kendi takiplerini alan bir milyon daha küçük çerçeve ve araç var ( Temel ihtiyaçlar için hız , ham JSP'ler , Struts, vb.). Yine de genellikle bileşen odaklı çerçeveleri tercih ederim.

Sonunda, sadece Tapestry, Wicket ve JSF'ye bir göz atmanızı ve sadece size en iyi hissettireni seçmenizi öneririm. Muhtemelen çok hızlı çalışmayı sevdiğin şekle uyan bir tane bulacaksın.


Web Uygulamanız bir forum sistemi gibi içerik tabanlıysa, GWT ve Ext-js kullanmanızı öneririm. Web Uygulamanız ERP terminali gibi bir masa uygulaması gibiyse, ZK, Echo3, Vaddin ve GWT kullanmanızı öneririm. Herhangi bir JSF çözümü önermeyeceğim çünkü "Bu JEE Standardı" olmadan bunları kullanmanın bir yararı bulamadım.
Zanyking

1
@Zanyking - Forumunuzun SEO'ya ihtiyacı varsa, GWT'yi zor bulacaksınız, imo.
jsight

3
JSF muhtemelen bir web sitesi için aşırıdır, bunun yerine daha üretken çerçeveler tercih ederim, ... geliştirme eğlenceli kalmalı ve JSF 'Eğlence' göz önünde bulundurularak inşa edilmemiştir :)
HeDinges

1
Tapestry, Wicket, JSF ve Echo'nun tümü bileşen odaklıdır ve GWT, Ext-js ve Vaadin Javascript odaklıdır. Spring MVC, Play framework, Grails ve Stripes gibi tüm harika "klasik" MVC çerçevelerine bir göz atmayı unutmayın. Eski modellerden çok farklı bir programlama modeline sahipler, ancak başka tatlı noktaları da var (bu yüzden bu kadar çok çerçeve var - farklı amaçlar, ihtiyaçlar ve tatlar farklı araçlar gerektirir).
DaGGeRRz

39

Benim favorim Bahar Çerçevesi. 2.5 Yaylı MVC, yeni açıklamalar, yapılandırma özellikleri üzerinde kural vb.

Sadece süper basit bir şey yapıyorsanız, sadece normal Servlet API'yi kullanmayı deneyebilir ve bir çerçeve ile uğraşmayabilirsiniz.


1
Basit bir şey için normal Servlet API kullanımından bahsetmek için oy verin.
lsiu

1
Wicket In Action'ın (ücretsiz) ilk bölümünde belirtilen nedenlerden dolayı, herhangi bir 'web mvc' çerçevesinden kaçınırdım. Ayrıca, tek sayfalı bir uygulamanız yoksa veya kendi çerçevenizi sıfırdan yazmak istemiyorsanız, Servlet API'yi doğrudan kullanmaktan kaçınırım.
Eelco

3
Spring'i de seviyorum, ancak tüm yapılandırmanın yalnızca mahoosive bir uygulama yazıyorsanız işe yaradığını gördüm.
Leonard Ehrenfried

1
Ek açıklamaları kullanan neredeyse hiç yapılandırma yoktur.
bpapa

1
@bpapa Ek açıklamalar yalnızca yapılandırmayı xml yerine java sınıflarınıza yerleştirir.
Steven

25

Bileşen odaklı Wicket çerçevesini öneririm . Web uygulamanızı düz eski Java koduyla yazmanıza olanak tanır, POJO'ları tüm bileşenler için model olarak kullanabilir ve büyük XML yapılandırma dosyalarıyla uğraşmanıza gerek kalmaz.

Wicket'i keşfettiğimde ve web uygulaması geliştirmenin ne kadar kolay olabileceğini görünce Struts ile bir çevrimiçi bankacılık uygulamasını başarıyla geliştirdim!


17

Yakın zamanda Stripes Framework'ü kullanmaya başladım . Kullanımı gerçekten kolay, ancak yaptığınız işe herhangi bir sınır koymayan, istek tabanlı bir çerçeve arıyorsanız, kesinlikle tavsiye ederim.

Payandalara benzer, ancak bunun ötesine geçer. Çok az yapılandırmayla hazırda bekletme veya jpa kullanmanıza olanak tanıyan bazı eklenti projeleri bile vardır.

Wicket'in de iyi olduğunu duymuş olsam da, pek çok iyi çerçeve var, ama kullanmadım.


16

Kendim denemedim ama sanırım

http://www.playframework.org/

çok fazla potansiyele sahip ...

php ve klasik asp'den geliyor, bana ümit verici görünen ilk java web çerçevesi ...


2
Bugünkü beşinci kez, stackoverflow'da "Kullanmadım, ancak Oynatmayı öneririm" i görmem komik.
Marko

11

GÜNCELLEME: Goblen 5.2 çıktı, bu yüzden daha önce göründüğü gibi terk edilmedi. Benim deneyimim Tapestry 4 ile ilgili, 5 değil, bu yüzden kilometreniz değişebilir. Tapestry hakkındaki görüşüm yıllar içinde değişti; Bu yazıyı yansıtacak şekilde değiştirdim.

Daha önce yaptığım gibi artık Tapestry'yi tavsiye edemiyorum. Tapestry 5 önemli bir gelişme gibi görünüyor, ancak Tapestry ile ilgili temel sorunum platformun kendisiyle ilgili değil; arkasındaki insanlarla birlikte.

Tarihsel olarak, Tapestry'nin her büyük sürüm güncellemesi, beklenenden çok daha fazla, aşırı önyargı ile geriye dönük uyumluluğu bozmuştur. Bu, önemli ölçüde yeniden yazım gerektiren yeni kodlama tekniklerinin veya teknolojilerinin dahil edilmesinden kaynaklanıyor gibi görünüyor.

Howard Lewis Ship (Tapestry'nin baş yazarı) kesinlikle mükemmel bir geliştirici, ancak Tapestry projesinin yönetimini önemsediğimi söyleyemem. Goblen 5'in geliştirilmesi, Goblen 4'ün gönderilmesinden hemen sonra başladı. Anladığım kadarıyla, Ship kendini buna adadı ve Tapestry 4'ü neredeyse Ship kadar yetenekli olmadığını düşündüğüm diğer katılımcıların ellerine bıraktı. Tapestry 3'ten Tapestry 4'e acı verici geçiş yaptıktan sonra, neredeyse hemen terk edildiğimi hissettim.

Elbette Tapestry 5'in piyasaya sürülmesiyle Tapestry 4 eski bir ürün haline geldi. Yükseltme yolu öylesine acımasız değildi ben bu bir sorun olmazdı tekrar . Öyleyse şimdi geliştirme ekibimiz oldukça inkar edilemez bir konumda: Esasen terk edilmiş bir web platformunu (Tapestry 4) kullanmaya devam edebilir, Tapestry 5'e iğrenç yükseltmeyi yapabilir veya Tapestry'den tamamen vazgeçebilir ve başka bir platform kullanarak uygulamamızı yeniden yazabiliriz. Bu seçeneklerin hiçbiri çok çekici değil.

Goblen 5, bu noktadan sonra güncellemenin kırılma olasılığını azaltmak için sözde yazılmıştır. İyi bir örnek, sayfa sınıflarıdır: önceki enkarnasyonlarda, sayfa sınıfları, Tapestry tarafından sağlanan bir temel sınıftan türemiştir; Bu sınıftaki uyumsuz API değişiklikleri, çok sayıda geriye dönük uyumluluk sorununun nedeniydi. Tapestry 5'te sayfalar, açıklamalar aracılığıyla "sihirli Goblen peri tozu" ile çalışma zamanında geliştirilmiş POJO'lardır. Ek açıklamalar için sözleşme korunduğu sürece, Goblen'de yapılan değişiklikler sayfa sınıflarınızı etkilemeyecektir.

Bu doğruysa, Tapestry 5 kullanarak yeni bir uygulama yazmak iyi sonuç verebilir. Ama şahsen, elimi tekrar brülöre koymak istemiyorum.


Güncelleme: Zaman geçtikçe, Goblen projesi terk edilmiş görünüyor. Nisan '09'dan bu yana hiçbir Tapestry 5 sürümü çıkmadı ve hala JIRA'larında bir dizi olağanüstü hata bulunan Tapestry 4, 2008'den beri bir güncelleme almadı. Bu nedenle, artık bir web uygulaması çerçevesi için uygun bir seçim olarak Tapestry'yi öneremiyorum.
Robert J. Walker

Goblen terk edilmedi. Tapestry 5 şubesi, istikrarlı seçenek olarak 5.1 ve yakında gelecek 5.2 ile oldukça aktif.
Timo Westkämper

Haklısın. Aslında, Tapestry 5.2 o zamandan beri piyasaya sürüldü. Yayını, Tapestry hakkındaki güncellenmiş görüşümü yansıtacak şekilde güncelledim.
Robert J. Walker

9

Disclamer: Vaadin'de çalışıyorum (daha önce IT Mill)

RIAish bir şey yapıyorsanız, Vaadin'e bakmak isteyebilirsiniz . Bu, benim için kullanımı güzel olan açık kaynak kullanıcı arayüzü odaklı bir AJAX çerçevesidir (ben de bir PHP arka planından geliyorum).

Icefaces ve Vaadin'de aynı uygulamayı (yani aynı özelliklere sahip iki uygulamayı) karşılaştıran bir vaka çalışması var. Özetle, UI geliştirmenin oldukça hızlı olduğunu belirtiyor.

Çalışma şirketin wiki'sinde barındırılsa da, sizi bana inanmaya zorlayamamama rağmen objektif, gerçek ve doğru olduğunu temin edebilirim.


+1 Çerçeve vaadin (daha önce ITMill) olarak yeniden markalandı. Vaadin'in çok güzel görünen bir web çerçevesi olduğunu ve tümüyle java'nın başka bir şey olmadığını söylemeliyim. Çok üretken buluyorum.
fmucar

7

Uzun bir süre çeşitli çözümleri test ettikten sonra, benim için şu çıktı:

  • Sunum ve denetleyici katmanı için Bahar MVC'si (Yine de Bahar Web Akışı YOK, çünkü akışlarım ajax'a dayanıyor)

  • Tüm istemci tarafı şeyler için jQuery

  • Güvenlik açısından Bahar Güvenliği

  • Hazırda bekletme / JPA2

  • Devam etme uğruna iskele (kuyruklu yıldız)

Bir aylık olağanüstü dik bir öğrenme eğrisi, ama şimdi mutluyum.

Ayrıca tüm bu Java şeylerini atlamaktan ve bunun yerine Scala / LIFT öğrenmekten sadece küçük bir adım uzakta olduğumu da belirtmek isterim. Endişelendiğim kadarıyla, Java'da son teknoloji web geliştirme ile ilgili her şey (kuyruklu yıldız, zaman uyumsuz iletişim, güvenlik (evet, Spring Security ile bile!)) Hala biraz hiledir (kanıtla yanlış olduğumu kanıtlayın, lütfen !). Bana göre Scala / LIFT, kullanıma hazır ve hepsi bir arada bir çözüm gibi görünüyor.

Sonunda karar sebebi değil Scala olduğu ile gitmek

  • Bir proje lideri olarak insan kaynaklarını ve Java geliştiricilerini bulmanın Scala geliştiricilerinden çok daha kolay olduğunu düşünmeliyim

  • Ekibimdeki çoğu geliştirici için, Scala'nın işlevsel konseptinin mükemmel olduğu kadar da anlaşılması zor

Şerefe Er


Bunların hepsi güzel şeyler. İyi bir seçim yaylı MVC, güvenli (ve bilge) tarafta kalın.
Victor Ionescu

5

Bahar Çerçevesi hakkında da güzel şeyler duydum. Genel olarak baktığım çoğu Java web çerçevesinden (esp Struts) yeterince etkilendim.

Basit bir uygulama için kesinlikle "ham" sunucu uygulamaları ve JSP'leri kullanmayı düşünür ve bir çerçeve benimsemekten endişe etmem. Sunucu uygulamaları iyi yazılmışsa, gelecekte, uygulama karmaşıklık içinde büyüdüğünde gerekirse bir çerçeveye bağlantı kurmak kolay olmalıdır.


1
"Servletler iyi yazılmışsa ..." için +1
Chris


4

Hepsi - sorun bu ;-)


3

Mütevazı gereksinimleriniz için, Tomcat sunucusundan hizmet verebileceğiniz servletleri veya basit jsp sayfalarını kodlamanız gerektiğini düşünüyorum. Kişisel web sitesi verileri için herhangi bir web çerçevesine (destekler gibi) ihtiyacınız olduğunu düşünmüyorum


3

"JSF kullan" demek biraz basittir. JSF kullanmaya karar verdiğinizde, üstüne bir bileşen kitaplığı seçmeniz gerekir. MyFaces Tomahawk, Trinidad, Tobago ( http://myfaces.apache.org/ ) kullanacak mısınız ? Veya belki ICEfaces ( http://www.icefaces.org/ )? Oh, ve ICEfaces kullanırsanız, görünümleriniz için JSP'leri veya Facelets'i mi kullanacaksınız?

Bence bunu söylemek zor. Hiç kimsenin umut vaat eden tüm alternatifleri değerlendirecek zamanı yok, en azından üzerinde çalıştığım projelerde, çünkü üç aylık değerlendirme aşamalarını yapacak kadar büyük değiller. Ancak, büyük ve aktif bir topluluğa sahip olan ve bir yıl içinde gitmemiş olanları aramalısınız. JSF bir süredir ortalıkta ve güneş tarafından itildiği için bir süre daha ortalıkta olacak. Bunun en iyi seçenek olup olmadığını söyleyemem ama iyi bir seçim olacak.


Jsp, sattığımız bir Web uygulamasını yaparken benim için bir acı oldu. Bir Güncelleme, bunun yerine yüzleri dikkate alır.
Thorbjørn Ravn Andersen

Evet, bu zamana kadar oldukça eminim: JSP yerine yüz karakterlerini kullanın. Çok daha iyi ve herhangi bir (büyük) dezavantaj görmüyorum.
Tim Büthe


3

Yüksek trafikli siteler için, sunucudaki istemci durumunu yönetmeyen bir çerçeve kullanırım - Wicket, JSF ve Tapestry, sunucudaki istemci durumunu yönetiyor. Uygulama bir masaüstü uygulaması gibi olması gerekiyorsa, yalnızca bu çerçeveleri (Wicket benim favorim) kullanırdım. Ancak daha ölçeklenebilir ve basit bir REST + AJAX yaklaşımı kullanmayı denerim.

Spring MVC bir aday olabilir, ancak Spring MVC 3'ten beri, statik yazmanın faydalarını kullanmayan garip bir ek açıklama aşırı yüklenmiş programlama modeline sahiptir. Normal bir dönüşle birleştirilmiş yöntemlerde çıktı parametreleri gibi başka çirkin şeyler de vardır, bu nedenle bir yöntemin iki çıktı kanalı vardır. Spring MVC ayrıca tekerleği yeniden keşfetme eğilimindedir ve diğer çerçevelere kıyasla yapılandırmanız gereken daha çok şeye sahip olursunuz. Bazı güzel fikirleri olmasına rağmen Spring MVC'yi gerçekten tavsiye edemem.

Grails, Spring MVC'yi ve Hibernate gibi diğer yerleşik çerçeveleri kullanmanın uygun bir yoludur. Kodlama eğlencelidir ve sonuçları çabucak görürsünüz.

Şablon oluşturma için FreeMarker gibi birkaç küçük yardımcıya sahip Servlet API'nin çok güçlü olduğunu unutmayın.



2

Seçimim Wicket (büyük projeler ve öngörülebilir bir kullanıcı tabanı için), GWT (çoğunlukla halka açık olan büyük projeler için) veya bir JavaScript araç setiyle birlikte (Jersey / JAXRS gibi) sadece bir hizmet çerçevesi (küçük ila orta ölçekli projeler için) olacaktır. .


2

Özellikle sebat etmeniz gerekiyorsa Seam'i tavsiye ederim.



1

İçin hızlı ve fantezi GUI sizinle JSF kullanabilirsiniz richfaces kütüphanesine. Richfaces UI bileşenlerinin kullanımı kolaydır ve demo sitesinde kod gösterimi ile birlikte kullanışlı referanslar mevcuttur. Muhtemelen daha sonra sitenizde işlenecek daha fazla veri olduğunda ve çok fazla bilginin veritabanında işlem görmesi gerektiğinde, herhangi bir veritabanı erişim çerçevesini (ORM) buna bağlayabilirsiniz.


0

Kimsenin GWT'den bahsetmediğine inanamıyorum


GWT'yi gerçekten bir web uygulama çerçevesi olarak görmezdim (daha çok bir web araç setine benziyor, dolayısıyla adı). Ancak GWT harika ve örneğin Bahar ile birlikte iyi gidiyor.
stian

çerçeve veya araç seti, somut fark gerçekten nedir? GWT ile kodlama, diğer seçenekler kadar bir çerçeve ile çalışmayı hissettirir.
Eelco



Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.