Tumpukan Java EE 6 vs. Spring 3 [ditutup]

90

Saya memulai proyek baru sekarang. Saya harus memilih teknologi. Saya butuh sesuatu yang ringan, jadi tidak ada EJB atau Seam. Di sisi lain saya membutuhkan JPA (Hibernate atau alternatif) dan JSF dengan IceFaces.

Apakah menurut Anda tumpukan seperti itu pada Spring 3 yang digunakan di Tomcat adalah pilihan yang baik? Atau aplikasi web Java EE 6 bisa lebih baik? Saya khawatir Java EE 6 adalah teknologi baru, belum terdokumentasi dengan baik. Tomcat tampaknya lebih mudah dirawat daripada Glassfish 3.

Apa pendapatmu? Apakah Anda punya pengalaman?

java  spring  jsf  jakarta-ee  java-ee-6 
— Piotr Gwiazda
sumber
8
Saya akan memilih primefaces.org daripada IceFaces jika Anda menginginkan cahaya. Ini jauh lebih cepat dan api yang lebih ramping.
— Shervin Asgari
1
Saat ini hanya ada Glassfish yang menyediakan JEE6. Resin perlahan menerapkan profil web JEE6 , yang mungkin cukup untuk Anda tergantung pada apa yang Anda butuhkan.
— Thorbjørn Ravn Andersen
3
@ Thorbjørn Anda dapat menggunakan Profil Web GlassFish v3 jika Anda hanya menginginkan profil web.
— Pascal Thivent
@Pascal, sudah dijelaskan bahwa akan segera ada alternatif untuk Glassfish untuk mendapatkan JEE6 jika Anda dapat hidup dengan profil web (saya bisa), bukan untuk mengatakan bahwa Glassfish tidak bisa.
— Thorbjørn Ravn Andersen
@ Thorbjørn Saya lupa menghapus @ Thorbjørn :) Komentar ini ditujukan untuk OP yang tampaknya berasumsi bahwa menggunakan GFv3 "full-stack" adalah satu-satunya pilihan.
— Pascal Thivent

Jawaban:

101

Saya butuh sesuatu yang ringan, jadi tidak ada EJB atau Seam.

Maukah Anda menjelaskan apa yang membuat EJB berat sejak EJB3? Apakah Anda menyadari bahwa kita tidak berada di tahun 2004 lagi? Saya sangat ingin membaca definisi Anda tentang cahaya dan argumen Anda (dan saya akan memperbarui jawaban saya dengan senang hati karena saya cukup yakin saya akan memiliki beberapa hal yang solid untuk dikatakan).

Di sisi lain saya membutuhkan JPA (Hibernate atau alternatif) dan JSF dengan IceFaces.

Profil Web Java EE 6 yang mencakup JSF 2.0, JPA 2.0, Validasi Bean, EJB 3.1 Lite, CDI, ... akan sempurna untuk ini dan Anda dapat menggunakan Profil Web GlassFish v3 untuk menjalankan aplikasi yang dibangun dengan Profil Web Java EE 6 .

Apakah menurut Anda tumpukan seperti itu pada Spring 3 yang digunakan di Tomcat adalah pilihan yang baik? Atau aplikasi web Java EE 6 bisa lebih baik?

Nah, saya menyukai ide untuk menjalankan kode saya pada platform yang non-proprietary (Java EE) bukan pada wadah proprietary (musim semi). Dan menurut saya Java EE 6 sudah cukup baik (dan ini adalah eufemisme, EJB 3.1 (Lite), JPA 2.0, JSF 2.0, CDI kick ass). Perhatikan bahwa saya adalah seorang skeptis JSF tetapi saya melihat kedua dan JSF 2.0 dengan CDI sangat berbeda sehingga saya bahkan tidak dapat membandingkannya. Dan jika Anda tidak melihat CDI, izinkan saya memberi tahu Anda bahwa itu keren.

Saya khawatir Java EE 6 adalah teknologi baru, belum terdokumentasi dengan baik.

Java EE terlihat cukup baik untuk saya. Ini terdengar seperti klaim gratis. Dan, percaya atau tidak, saya mulai menemukan Spring semakin rumit sementara Java EE semakin mudah.

Tomcat tampaknya lebih mudah dirawat daripada Glassfish 3.

Apakah kamu mencoba sesuatu? Apakah Anda menghadapi masalah tertentu? Sekali lagi, ini terdengar seperti klaim gratis.

— Pascal Thivent
sumber
2
Saya hanya mengejar proyek besar penilai yang dikembangkan dengan EJB3.0 + Seam on JBoss dengan Drools, GraniteDS, dan banyak lagi. Saya setuju Seam rocks! Tapi saya menghabiskan 50% pengembangan untuk pemindahan, memulai ulang server, kesalahan penerapan, membersihkan direktori temp, dll. Di sisi lain, kinerja JBoss Tools sangat buruk (maksud saya benar-benar - ruang ctrl + dan 10s hang) Hal ini benar-benar membuat saya enggan menggunakan JEE6 yang terlihat seperti dipinjam dari kerangka Seam. Sedangkan untuk server saya tidak mau memikirkan conecion pools, jndi, jms, jmx, ear deplyment. Saya butuh sesuatu untuk menyalakan WAR dan bekerja dalam hitungan detik.
— Piotr Gwiazda
6
@peperg Gaving King adalah pemimpin spesifikasi CDI (Weld being the RI) sehingga Anda akan menemukan kesamaan antara Seam dan CDI. Tapi CDI! = Seam, Java EE 6! = Seam, salah persepsi kamu. Mungkin mencoba Profil Web GlassFish v3, Anda akan terkejut (dan setelah kumpulan koneksi ditentukan, tidak banyak yang perlu dikhawatirkan).
— Pascal Thivent
8
Ada apa dengan orang mengatakan EJB itu berat ?. Saya menggunakan EJB v3.1 dan mereka hanyalah pojos beranotasi. Ketika mereka mengatakan berat, apa yang mereka maksud dalam kinerja atau apa?
— arg20
13
@ arg20 - Itu memang pertanyaan besar dan Pascal berhak meminta untuk menjelaskan apa arti istilah "berat" (atau "ringan") dalam konteks ini. Kemungkinan besar itu adalah sisa dari perseteruan lama antara Spring dan EJB. Pada awalnya, EJB1 & 2 secara konseptual berat. Penekanan berlebihan pada kacang jarak jauh dan stateful, deskriptor penerapan XML yang sangat bertele-tele dan jumlah antarmuka yang diperlukan untuk diimplementasikan yang benar-benar gila memberi mereka reputasi yang sangat buruk. Dengan EJB3 (2006) ini telah benar-benar berubah, tetapi orang-orang yang meninggalkan EJB pada tahun 2004 karena musim semi terkadang masih menganggap 2004 dan EJB2 adalah yang terbaru.
— Arjan Tijms
7
Perhatikan bahwa di halaman Tentang Spring tertulis "Kami percaya bahwa: J2EE harus lebih mudah digunakan". Perhatikan bahwa mereka menggunakan istilah "J2EE" dan bukan "Java EE", yang merupakan nama yang benar sejak Java EE 5 dirilis (menurut saya). Ini menjelaskan banyak hal tentang mereka ...
— Vítor E. Silva Souza
32

Saya belum menggunakan JavaEE6.

Namun, saya telah dipukuli cukup parah oleh semua versi JavaEE dan EJB sebelumnya sehingga saya tidak akan mempercayainya sampai ia menetapkan dirinya sebagai standar de facto, bukan hanya standar de jure. Saat ini, Musim Semi masih menjadi standar de facto.

Menipuku sekali, malu padamu. Menipu saya dua kali, saya malu. Menipu saya tiga kali, EJB.

Beberapa orang akan mengklaim bahwa Spring adalah hak milik. Saya berpendapat bahwa implementasi vendor dari spesifikasi JavaEE telah menjadi hak milik, jika tidak lebih.

Saya mengalami konversi besar baru-baru ini untuk memindahkan sekelompok Aplikasi Java dari JBoss ke Weblogic. Semua aplikasi Spring / Hibernate di-porting tanpa modifikasi, karena mereka memiliki semua library yang mereka butuhkan di dalamnya. Semua aplikasi yang menggunakan JPA dan EJB dan JSF adalah malapetaka untuk port. Perbedaan halus dalam interpretasi JPA, EJB, dan JSF antar server aplikasi menyebabkan semua jenis bug buruk yang membutuhkan waktu lama untuk diperbaiki. Bahkan sesuatu yang sederhana seperti penamaan JNDI benar-benar berbeda antara AppServers.

Spring adalah sebuah implementasi. JavaEE adalah sebuah spesifikasi. Itu adalah perbedaan BESAR. Saya lebih suka menggunakan spesifikasi JIKA spesifikasi itu 100% kedap udara dan sama sekali tidak memberikan ruang gerak dalam cara vendor menerapkan spesifikasi itu. Tetapi spesifikasi JavaEE tidak pernah seperti itu. Mungkin JavaEE6 lebih kedap udara? Saya tidak tahu. Semakin banyak Anda dapat mengemas dalam WAR Anda, dan semakin sedikit Anda bergantung pada pustaka AppServer, aplikasi Anda akan semakin portabel, dan bagaimanapun juga, itulah alasan saya menggunakan Java dan bukan Dot-NET.

Bahkan JIKA speknya kedap udara, alangkah baiknya dapat meningkatkan server aplikasi tanpa harus memutakhirkan semua tumpukan teknologi saya di semua aplikasi saya bersama dengannya. Jika saya ingin meningkatkan dari JBoss 4.2 ke JBoss 7.0, saya harus mempertimbangkan dampak dari versi JSF yang lebih baru pada semua aplikasi saya. Saya tidak perlu mempertimbangkan dampaknya pada aplikasi Spring-MVC (atau Struts) saya.

— Gelas kimia
sumber
1
Tepat sekali, ini adalah alasan yang bagus.
— Palesz
1
Saya setuju dengan alasan ini, banyak masalah yang saya hadapi terkait dengan ketergantungan pada implementasi penampung spesifikasi. Secara signifikan mengurangi rasa sakit dari perpustakaan yang disematkan. Sulit untuk membantah, di luar preferensi filosofis dari sebuah spesifikasi.
— Peter Porter
Alasan yang bagus. Namun apakah ini pengalaman Anda bahkan setelah JEE 6? Saya memahami penerapan spesifikasi Server Aplikasi masih bisa menyusahkan - oleh karena itu spesifikasi yang sama yang diterapkan oleh Server Aplikasi 1 mungkin sederhana dan efisien sementara tidak untuk Server Aplikasi 2
— Soumya
1
+1. juga, server aplikasi berubah pada jadwal Operasi, di mana pegas / hibernasi berada di bawah kendali pengembang. di lingkungan perusahaan besar, mengupgrade server aplikasi adalah masalah yang jauh lebih besar.
— Nathan Hughes
Saya tidak benar-benar mengerti maksudnya tentang Dot-Net. Ini adalah kepemilikan sebanyak Spring dan dikembangkan oleh vendor tunggal yaitu Microsoft. Bisakah dijelaskan?
— pengguna1339260
23

Tidak masalah. Java EE 6 sudah cukup baik dan karena profil di sana, tidak "berat" - Anda hanya akan menggunakan profil web.

Secara pribadi, saya lebih suka Spring. Tapi saya kehabisan argumen rasional terhadap Java EE 6 :)

(Saat saya diingatkan oleh sebuah komentar - Anda mungkin ingin mencoba RichFaces , serta ICEfaces dan / atau PrimeFaces - tergantung pada komponen apa yang Anda butuhkan).

— Bozho
sumber
1
Jadi pertanyaannya adalah: "Apakah masuk akal untuk menggunakan Server Aplikasi Glassfish tumpukan penuh hanya dengan menggunakan profil web"?
— Piotr Gwiazda
1
@peperg Gunakan Profil Web GlassFish v3 jika Anda hanya ingin profil web, lihat jawaban saya.
— Pascal Thivent
Saya telah memposting beberapa argumen di sini stackoverflow.com/questions/2822812/spring-3-0-vs-j2ee-6-0/… , alih-alih diambil dari sudut pandang "bagaimana memasukkannya ke dalam produksi". Jadi mungkin itu mengisi argumen Anda sedikit.
— Oliver Drotbohm
@peperq, JBoss 6 dirilis selama liburan.
— Thorbjørn Ravn Andersen
17

Baru-baru ini, salah satu tugas klien saya melibatkan evaluasi tumpukan kerangka kerja Spring Stack Vs Custom Vs a Java EE Standards. Setelah sebulan evaluasi dan pembuatan prototipe, saya tidak hanya senang tetapi terpesona oleh rangkaian fitur Java EE 6. Untuk arsitektur proyek "perusahaan" baru di tahun 2011 dan selanjutnya, saya akan menggunakan Java EE 6 dan ekstensi potensial seperti Seam 3 atau proyek ekstensi Apache JSR299 yang akan datang. Arsitektur Java EE 6 disederhanakan dan menggabungkan yang terbaik dari banyak ide open source yang telah berkembang dalam beberapa tahun terakhir.

Pertimbangkan fitur berikut di luar kotak: Manajemen Peristiwa, Konteks dan DI, Interceptors, Dekorator, layanan web RESTful, pengujian terintegrasi dengan penampung yang dapat disematkan, Keamanan, dan banyak lagi.

Sebagian besar hasil saya dipublikasikan di blog saya yang menjelaskan konsep utama Java EE 6 yang mungkin berguna bagi Anda.

Tentu saja, tidak ada aturan pasti untuk memilih kerangka kerja. Java EE 6 bisa jadi sangat besar untuk "situs web" sederhana yang tidak memerlukan status sesi percakapan yang kaya. Anda mungkin juga memilih Grails atau Mainkan! Kerangka. Tetapi untuk aplikasi web percakapan, saya tidak dapat melihat argumen yang lebih baik mengapa Java EE 6 tidak cocok.

— pri
sumber
Java EE 6 hanya sangat lambat, profil web glassfish dan glassfish sangat lambat untuk mulai membandingkannya dengan jetty / tomcat / apa saja. Pengujian, penampung yang dapat disematkan juga sangat lambat.
— Palesz
15

Sekarang, setelah beberapa waktu, saya memiliki pengalaman dengan tumpukan:

  • Java EE 5 + Seam + GraniteDS + Flex
  • Musim Semi 3 + Vaadin (di GWT)
  • Musim Semi 3 + JSF 2.0 (PrimeFaces)

Colclusions saya adalah:

  • Spring 3 jauh lebih sederhana daripada Seam (hampir Java EE 6) dan berjalan di Tomcat dan Jetty! (Jetty untuk pengembangan dengan plugin maven adalah sebuah trasure).
  • Saya suka Flex (saya sebenarnya adalah pengembang Flex untuk waktu yang lama jadi saya bias) dan jika Anda membutuhkan antarmuka yang kaya dan dapat membeli FlashBuilder gunakan ini, tetapi gunakan backend Spring + GraniteDS atau BlazeDs ini. Jika Anda tidak dapat membeli FlashBuilder jangan buang waktu Anda.
  • Vaadin luar biasa !. Proses pengembangan lebih sederhana daripada Flex, tetapi Anda dapat membuat aplikasi yang kaya dengan mudah tanpa kekacauan HTML. Anda tidak akan menulis baris JS menghanguskan. Anda hanya perlu beberapa CSS (di Flex Anda juga membutuhkannya). Jadi, jika antarmuka aplikasi Anda akan berperilaku seperti aplikasi desktop dan Anda tidak dapat (atau tidak ingin) menggunakan Flex - gunakan Vaadin. Peringatan! Vaadin memiliki overhead JS yang besar untuk browser.
  • Jika Anda membuat aplikasi seperti situs web yang lebih sederhana, gunakan JSF2.0 (dengan spring backend seperti di atas). Anda harus berjuang dengan HTML (saya benci) dan membuat antarmuka yang kaya akan lebih sulit daripada Vaadin (terutama tata letak). Anda akan mendapatkan HTML ringan untuk browser / compuetrs yang lebih lambat. Saya suka PrimeFaces - mudah dan didokumentasikan dengan baik. Tempat kedua adalah IceFaces
  • Jika Anda membuat situs web (BUKAN aplikasi web) di mana Anda perlu menghidupkan HTML (daripada membuat aplikasi perusahaan yang cocok dengan browser) gunakan Wicket (jika Anda lebih suka berbasis komponen, sikap tarik) atau SpringMVC (jika Anda lebih suka berbasis template , mendorong sikap) atau cukup gunakan Play! kerangka. Ingatlah bahwa membuat komponen berbasis data yang kaya akan jauh lebih sulit tetapi Anda akan memiliki kendali atas setiap tag html (desainer HTML / Grafik Anda akan menyukainya)
— Piotr Gwiazda
sumber
21
Saya tidak mengerti bagaimana jawaban Anda sendiri berhubungan dengan pertanyaan ...
— Pere Villega
1
-1 Tampaknya sangat tidak pantas untuk menerima jawaban ini, karena jawaban ini bahkan tidak menyebutkan Java EE 6. Selain itu, jawaban ini tidak membahas poin apa pun yang diangkat dalam pemikiran yang matang dari @Pascal Thievent (dan lebih banyak lagi yang dipilih) menjawab.
— pengguna359996
1
Sebenarnya pertanyaan tidak lebih valid. JEE 6 sekarang sudah sangat matang, bukan pada Maret 2010 ketika pertanyaan itu diajukan.
— Piotr Gwiazda
@PiotrGwiazda dengan cara apa JEE 6 berubah sejak saat itu? Orang-orang lebih takut saat itu, tetapi pada dasarnya JEE 6. yang sama
— ymajoros
1
Maksud saya, implementasi JEE6 lebih matang dan tersedia. JBoss 7 sekarang stabil dan ada lebih banyak implementasi yang tersedia. Komunitas sekarang juga lebih besar. Lebih banyak alat dan lib sekarang mendukung tumpukan JEE 6.
— Piotr Gwiazda
8

Baca Masa Depan Perusahaan Java Adam Bien ... Is Clear (Java EE dengan / tanpa Spring dan Sebaliknya) , termasuk komentar untuk mendapatkan kedua sisi mata uang. Saya akan memilih Spring karena beberapa alasan dan berikut adalah salah satunya (mereproduksi salah satu komentar dari posting)

'Saya tidak yakin server Java EE 6 mana yang Anda bicarakan. Ada Glassfish bersertifikat dan TMAX JEUS. Ini akan memakan waktu cukup lama (baca: bertahun-tahun) sampai versi WebSphere, WebLogic, JBoss dll yang sesuai dengan Java EE 6 dalam produksi dan dapat digunakan untuk aplikasi nyata. Spring 3 hanya membutuhkan Java 1.5 dan J2EE 1.4 sehingga dapat dengan mudah digunakan di hampir semua lingkungan '

— Adisesha
sumber
6
Kami hampir tepat satu tahun kemudian dan JBoss AS 6, yang mendukung Java EE 6, saat ini digunakan dalam produksi.
— Arjan Tijms
8

Pendapat saya didasarkan pada sesuatu yang tidak disebutkan oleh orang lain, yaitu bahwa kode di tempat kerja saya cenderung bertahan selama puluhan tahun (literaly), dan karenanya pemeliharaan itu sangat penting bagi kami. Pemeliharaan kode kita sendiri, dan pustaka yang kita gunakan. Kode kita sendiri yang kita kontrol, tetapi untuk kepentingan kita perpustakaan yang kita gunakan, dipelihara oleh orang lain dalam dekade yang disebutkan di atas atau lebih.

Singkatnya, saya telah menyimpulkan bahwa cara terbaik untuk mencapai hal ini adalah dengan menggunakan implementasi open source spesifikasi Sun hingga ke JVM mentah.

Implementasi open source Apache Jakarta telah terbukti mempertahankan perpustakaannya, dan baru-baru ini Sun telah melakukan banyak pekerjaan dalam menghasilkan implementasi berkualitas tinggi untuk Glassfish v3. Bagaimanapun, kami juga memiliki sumber untuk semua modul, jadi jika semuanya gagal, kami dapat memeliharanya sendiri.

Spesifikasi Sun biasanya sangat ketat artinya implementasi yang sesuai dengan spesifikasi dapat dipertukarkan dengan mudah. Lihat saja wadah servlet.

Dalam kasus khusus ini, saya sarankan untuk melihat JavaServer Faces hanya karena ini adalah bagian dari Java EE 6 yang berarti akan tersedia dan dipelihara untuk waktu yang sangat, sangat lama. Kemudian kami memilih untuk menambahkan dengan MyFaces Tomahawk karena memberikan beberapa tambahan yang berguna, dan ini adalah proyek di Jakarta.

Tidak ada yang salah dengan JBoss Seam atau yang lainnya. Hanya saja fokus mereka kurang pada masalah perawatan yang begitu penting bagi kami.

— Thorbjørn Ravn Andersen
sumber
Ternyata Java ServerFaces 2 di Java EE 6 dapat melakukan sendiri apa yang kami butuhkan untuk Tomahawk dengan JSF 1. Ini adalah kerangka kerja yang cukup mumpuni (tapi agak berat XML)
— Thorbjørn Ravn Andersen
Hebatnya, sayangnya orang cenderung lupa bahwa perangkat lunak dibuat untuk hidup selama beberapa dekade dan bahwa dukungan jangka panjang adalah kunci yang sangat penting.
— timmz
6

Saya dapat melihat menggunakan Spring jika Anda sudah memilikinya, tetapi untuk proyek baru, apa gunanya? Saya akan langsung menggunakan Java EE 6 (ejb3, jsf2.0, dll.)

Jika klien setuju dengan Flex, lakukanlah. Gunakan BlazeDS atau yang serupa - tanpa MVC. Anda mungkin menghabiskan lebih banyak waktu di bagian itu (bertukar data antara server dan klien) tetapi Anda memiliki kendali penuh di kedua sisi.

Jangan gunakan Vaadin, kecuali Anda ingin mematikan browser Anda. Selain itu, Anda menghabiskan lebih banyak waktu untuk mempelajari kode setelah halaman Anda menjadi lebih kompleks. Selain itu, pola pikir Anda perlu diubah sepenuhnya dan apa pun yang Anda ketahui tentang pengembangan front end standar akan sia-sia. Argumen bahwa Anda tidak harus menggunakan HTML atau JS tidak masuk akal. Anda tetap harus mengetahuinya meskipun Anda tidak menggunakannya. Ini akan merender ke HTML dan JS pada akhirnya. Kemudian coba debug - pastikan Anda punya beberapa hari untuk hal-hal sederhana. Plus, saya tidak bisa membayangkan pengembang web yang tidak tahu html / js.

Saya hanya tidak mengerti mengapa orang mencoba semua abstraksi tersebut daripada menggunakan Java EE secara langsung.

— Marcin Koziarski
sumber
5

Mengapa masih ada kabar burung tentang EJB menjadi kelas berat di tahun 2010? Sepertinya orang tidak diperbarui dalam teknologi Java EE. Coba saja, Anda akan terkejut dengan betapa disederhanakannya berbagai hal di Java EE 6.

— nash
sumber
4

Jawaban atas pertanyaan Anda bergantung pada persyaratan proyek Anda. Jika Anda tidak memerlukan fitur Java EE seperti antrian pesan, transaksi global yang dikelola kontainer, dll., Gunakan tomcat + spring.

Juga dari pengalaman saya telah menemukan bahwa proyek yang membutuhkan banyak integrasi layanan web, penjadwalan, antrian pesan paling baik dilakukan menggunakan beberapa tumpukan Java EE. Hal baiknya adalah dengan menggunakan pegas Anda masih dapat berintegrasi dengan modul Java EE yang berjalan di server aplikasi.

Java EE 6 sangat berbeda dari rilis sebelumnya, dan itu benar-benar membuat segalanya menjadi lebih mudah. Java EE 6 menggabungkan ide-ide terbaik dari komunitas Java yang beragam - misalnya Rod Johnson dari framework Spring secara aktif terlibat dalam pembuatan Dependency Injection JSR di Java EE 6. Manfaat menggunakan Java EE 6 adalah Anda membuat kode sesuai dengan standar, yang mungkin penting dalam beberapa organisasi untuk dukungan vendor, dll.

GlassFish v3 mendukung Java EE 6 dan cukup ringan serta memulai dengan sangat cepat. Saya telah menggunakan glassfish v3 untuk perkembangan saya, dan sangat mudah untuk dikonfigurasi. Muncul dengan konsol admin yang sangat ramah pengguna yang memungkinkan Anda mengelola server secara grafis.

Jika Anda menggunakan GlassfishV3 dan JSF 2, Anda dapat memanfaatkan fitur CDI Java EE 6, yang memungkinkan Anda membuat percakapan dengan mudah (misalnya halaman seperti wizard) di JSF.

Karena itu, menggunakan Java EE 6 juga mengharuskan Anda mempelajari API baru. Bergantung pada jangka waktu yang tersedia, ini mungkin bukan pilihan terbaik untuk Anda. Tomcat telah ada sejak lama, dan kombinasi tomcat + spring telah diadopsi oleh banyak proyek web, yang berarti ada banyak dokumentasi / forum.

— Raz
sumber
Saya tidak setuju dengan kalimat pertama Anda, pilihannya bukan tentang menggunakan JMS atau tidak. Dan menurut saya JSR-330 tidak begitu penting di Java EE 6 (lebih karena alasan politik), bagian yang penting adalah JSR-299 (CDI). Setidaknya, inilah pendapat saya.
— Pascal Thivent
Setuju ada beberapa politik yang melibatkan JSR330 - namun ini cukup penting karena memberikan dasar umum untuk injeksi ketergantungan di Java (SE atau EE) daripada menjadikan DI teknologi khusus JEE. Selain itu, ini didukung oleh kerangka kerja Spring dan Google Guice, yang berarti akan membuat kode Spring / Guice mudah ditransfer ke JEE6 atau sebaliknya. JSR299 juga dirancang untuk memperluas fitur-fitur di JSR330. Anda benar karena untuk aplikasi web di JEE6, JSR299 sangatlah penting. Berkat dua JSR ini, JEE6 & Spring keduanya memiliki model pemrograman yang sangat mirip. Terima kasih atas komentar Anda!
— Raz
3

Saya telah bekerja di Spring dan Java EE 6. Apa yang dapat saya katakan dari pengalaman saya adalah bahwa Jika Anda menggunakan JSP lama atau Flex berpemilik, maka Anda aman jika tetap menggunakan Spring.

Tetapi jika Anda ingin melanjutkan dengan JSF maka inilah waktunya untuk beralih ke Java EE 6. Dengan Java EE 6 Anda pindah ke Facelet dan pustaka skrip standar dan pustaka komponen. Tidak ada lagi ketidakcocokan skrip dan matriks pustaka komponen.

Mengenai Spring MVC, ada baiknya selama proyek Anda tidak berkembang terlalu besar. Jika itu adalah aplikasi perusahaan besar, tetap gunakan Java EE 6. Karena itulah satu-satunya cara Anda dapat memelihara pustaka komponen dan bundel sumber daya Anda sendiri secara teratur.

— pengguna373480
sumber
1
Terima kasih atas komentar Anda. Pilihan saya adalah Spring + Vaadin.
— Piotr Gwiazda
3

Jika Anda membutuhkan tumpukan penuh Java EE, saya sarankan Anda GlassFish 3.1. Ini dimulai dengan sangat cepat dibandingkan dengan kontainer Java EE lainnya yang mengimplementasikan sebagian atau seluruh Java EE 6 (JBoss 6, WebLogic 10.3.4), penyebaran ulang membutuhkan waktu beberapa detik dan hampir semua dapat dilakukan dengan konvensi atas konfigurasi, ini sangat ramah.

Jika Anda menginginkan sesuatu yang "Ringan", Anda dapat menyesuaikan Apache Tomcat 7.x dengan fitur yang diinginkan. Saya sering menggunakan pustaka berikut: Weld 1.1.0 (CDI) JPA 2.0 (Hibernate 3.6.x) - hanya sumber daya transaksi lokal JSF 2.x (Mojarra) RichFaces 4.0 BIRT runtime

Menjadi pengembang Java EE selama 10 tahun terakhir (saya menderita EJB awal, JSF dan teknologi web), Java EE 6 sangat mudah, digabungkan dengan baik dan perangkat keras saat ini berjalan mulus sehingga alasan asli yang memotivasi Spring tidak lagi valid.

— ssamayoa
sumber
1
Saya suka jawaban Anda. Sangat masuk akal. Ketika saya memposting pertanyaan JEE6 masih sangat muda dan Tomcat 7 belum selesai. "alasan asli yang memotivasi Spring tidak lagi valid" - itu benar, tetapi JEE6 dengan CDI perlu waktu untuk pulih. Sebagai contoh: Pemantauan Javamelody tersedia untuk Spring dan Guice (Saya tidak dapat membayangkan akan memperburuk aplikasi tanpa itu). EHcache tersedia untuk Spring (maksud saya hasil metode caching). Banyak hal seperti pemrograman aspek masih lebih mudah di Spring, karena banyak library dan framework pihak ketiga terintegrasi dengan mudah dengan Spring tetapi belum dengan JEE6.
— Piotr Gwiazda
1

Saya masih lebih suka Spring.

Dan saya akan meneruskan JSF. Saya pikir itu adalah teknologi yang mati. MVC musim semi akan menjadi alternatif yang lebih baik. Begitu juga dengan Flex. Pikirkan dalam hal kontrak layanan XML pertama dan Anda dapat memisahkan back end dari UI sepenuhnya.

— duffymo
sumber
1
Saya telah membuat beberapa aplikasi dengan Java + Flex dan PHP + Flex dan saya setuju bahwa ini adalah solusi terbaik untuk antarmuka yang kaya. Tetapi dalam aplikasi ini saya tidak dapat menggunakan Flex :( Saya memerlukan beberapa antarmuka tingkat tinggi, jadi Spring MVC bukanlah solusi. Saya ingin memikirkan tentang data yang dapat diurutkan daripada <tr> <td> dalam satu lingkaran.
— Piotr Gwiazda
1
@ Duffymo - Saya bisa berdebat apakah flex adalah pilihan yang baik. JSF jelas tidak mati, terutama dengan pustaka seperti richfaces, primefaces, icefaces, dll.
— Bozho
1
Di IceFaces saya membuat menu, pohon, datagrid menggunakan tindakan, peristiwa dan saya tidak berpikir jika halaman dimuat ulang atau permintaan ajax. Sebuah datagrid yang dapat diurutkan atau pohon yang dimuat ajax adalah komponen buil-in. Di musim semi MVC saya beroperasi pada HTML - tabel, daftar, dll. Saya perlu menggunakan beberapa kerangka kerja javascript pihak ketiga dan membuat keajaiban AJAX dengan tangan. Saya ingin melakukannya di Flex tetapi ini adalah keputusan politik / bisnis - bukan keputusan saya.
— Piotr Gwiazda
1
Dua proyek JSF saya saat ini pasti tidak mati;) Dan saya jauh lebih puas dengan cara JSF untuk membangun RIA ("kaya" dalam "richfaces" adalah untuk itu), daripada menggunakan Flex. Seseorang bahkan akan go public minggu depan.
— Bozho
2
Saya benar-benar ingin tahu mengapa Anda masih lebih suka Spring, Java EE 6 sangat bagus. Tidakkah Anda berpikir bahwa menjalankan platform terbuka itu penting untuk masa depan Java?
— Pascal Thivent
0

Saya akan merekomendasikan Spring + Tomcat kecuali Anda bisa menunggu waktu untuk glassfish v3 dan Weld menjadi lebih dewasa. Saat ini ada beberapa masalah dengan konsumsi memori / beban cpu saat menjalankan glassfish dengan aplikasi berkemampuan CDI.

0

Tidak membaca semuanya tetapi hanya untuk memberitahu bahwa Anda sekarang dapat menggunakan EJB3 di dalam perang di Java EE 6 sehingga Anda dapat menggunakan EJB3 di Tomcat (menurut saya).

— Sebastien Lorber
sumber
Ya, Anda dapat mengemas EJB dalam WAR di Java EE 6 tetapi ini tidak berarti Anda dapat menerapkan WAR seperti itu di Tomcat. Anda memerlukan wadah yang mengimplementasikan Profil Web dan Tomcat tidak dan sebenarnya tidak ada rencana di komunitas Tomcat untuk menerapkannya (lihat old.nabble.com/Java-EE-6-Web-Profile-td27715793.html ). Tetapi ada Profil Web GlassFish v3, akan ada Resin ...
— Pascal Thivent
2
pembaruan: lihat proyek TomEE
— gpilotino
-3

Saya merekomendasikan kepada Anda Tomcat dengan Spring karena:

  1. Spring dapat membuat kacang pendukung untuk JSP
  2. Anda akan menggunakan Spring untuk mempertahankan objek melalui JPA

Ini adalah pilihan yang baik untuk memilih Tomcat karena Anda tidak memerlukan pemrosesan kelas berat

— bassem
sumber
1
"Pemrosesan kelas berat"? Bisakah Anda menjelaskannya? Saya penasaran.
— Pascal Thivent
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.