Soru CRUD: Roo'ya mı yoksa Roo'ya değil mi? [kapalı]


CRUD uygulamaları için Groovy'yi Rails üzerinde kullanıyorum. Artık Grails kullanmaya izin verilmeyen yeni bir projeye başlıyorum (izin verilen kavanoz ve gradların bir listesi var orada değil).

Spring ROO veya JBoss Seam'i kullanmayı düşünüyorum. Nasıl karşılaştırırlar? Onların güçlü yanları ve zayıf yönleri nelerdir?


32
2017-11-22 08:04


Menşei


Bununla da ilgilenirim. Henüz kimsenin cevap vermediğine şaşırdım ... belki biraz teşvik edici yardım eder. :) - Andrew Eisenberg
Lütfen imza eklemeyin Sorularınıza / cevaplarınıza. - meagar♦
Eğer gerçekten size yardım ederse cevabı kabul etmeyi unutmayın. - Tim


Cevaplar:


Spring Roo ve JBoss Seam'in doğrudan karşılaştırılamayacağına dikkat edin, çünkü JBoss Seam'in kendisi de söz konusu CRUD uygulama üretimini sağlamaz. Ancak JBoss Seam, bu işlevselliği sağlayan dikiş-gen aracıyla birlikte gelir. Bu nedenle, JBoss Seam'in Spring framework ile karşılaştırılabilir olduğunu görmek ve dikiş-gen aletini Spring Roo ile karşılaştırmak daha iyi olacaktır. Bunun da tam bir karşılaştırma olmadığını biliyorum, ama sanırım bu oyunun dışında. Belirtilmesi gereken, JBoss Seam'e atıfta bulunduğumda, cevabın JB-dikişine, dikiş-gen aracıyla bağlantılı olarak bahsetmek olduğudur.

Hem Spring Roo hem de JBoss Seam (dikiş-gen ile), CRUD uygulamalarının yaratılmasını gerçekten çok kolay hale getiriyor, tıpkı diğer Java tam yığın / iskele çözümleri gibi Çerçeve oyna ve yaygın de yap. Eğer mevcut olan bir veri tabanına dayanarak veya varlıkları ekleyerek ve alanları ve ilişkileri tanımlayarak yeni bir temel CRUD uygulamasının ne kadar hızlı olduğunu ve nasıl çalıştığını (dikiş-gen ile Spring ROO ve JBoss Seam) karşılaştırırsanız, Bu kadar fark yok. Benim deneyimime göre Spring Roo'da bunu (biraz) biraz daha hızlı yapabilirsin, ama her ikisiyle de bir saatten daha az bir sürede (mevcut bir veritabanında) veya bir gün içinde (yarım) günde durumda tüm varlıkları ve ilişkileri eklemek zorundasınız).

Devam etmeden önce okuyucu, bu karşılaştırmanın her iki çözümle alçakgönüllülük deneyimime dayanarak yapıldığını ve bu nedenle Spring Roo sürüm 1.1.0 ve JBoss Seam 1.2 ve 2.x sürümlerini temel aldığını not etmelidir. Okuyucunun, şu anda, Java EE 6 spesifikasyonuna dayanan, halihazırda mükemmel bir Seam 3 versiyonu (aslında Seam modül ekli CDI (Weld)) bulunduğunu, ancak JBoss Seam'in bu yeni versiyonunun artık dikişe sahip olmadığını da dikkate almalıyız. gen uygulama ve bu nedenle henüz bir RoHS uygulaması yaratma işlevselliği henüz bir çift Spring Roo ve JBoss Seam 2.x ve alt gibi komutları ile var. Şu an JBoss’dan benzer bir şey üzerinde çalışan insanlar var. JBoss ForgeÇok umut verici görünen, ancak bugün itibariyle, gerçek bir tahliyeye henüz sahip olmadı ve bu yüzden henüz tahmin edilemeyen bir seçenek değil.

Spring Roo ve JBoss Seam'in (dikiş-gen ile) her ikisi de güzel bir temel CRUD uygulaması yaratıyor olsa da, Spring Roo'nun varsayılan UI tasarımı, benim düşünceme göre biraz daha iyi görünüyor, ancak muhtemelen yine de onu dinlendirmek istiyorsanız her ikisi için de bir argüman değil. Oluşturulan web uygulamaları, sunulan işlevsellikte biraz farklıdır, ancak temel CRUD işlevselliği ve kimlik doğrulama ve uluslararasılaştırma gibi diğer temel özellikler kadarıyla, birbirleriyle eşittirler.

Temel farklılıkların ve dolayısıyla gitmek istediğiniz kararın nedenleri, temel bir CRUD uygulaması oluşturmak için değil, iskelelerdeki temel CRUD uygulamalarında değil, mimarlık / tasarım gibi çok daha önemli şeylerde değil. kararlar, kullanım, destek, dökümantasyon, esneklik, süreklilik, uzatma noktaları vb. Bildiğim kadarıyla, hem Spring Roo hem de JBoss Seam, web uygulamanızı temel almak için harika seçenekler. her iki ile de üretim uygulaması), ancak bir karar vermeden önce, bu önemli farklılıklara bakmak ve sizin için en uygun olana karar vermek zorundasınız. Tabii ki, karar vermenin en iyi yolu, her iki seçenekle de kendiniz için bir kavram kanıtı yapmak olacaktır, ancak zamanınız ve / veya kaynaklarınız yoksa, işte size gelebilirim: Benim kafamın) Bu ikisi arasındaki farklar ve bu iki şekilde karar vermenize yardımcı olabilir:

  • Spring Roo'da kullanılan temel yapı sistemi, JBoss Seam'in Ant'i kullandığı Maven'dir. Dikiş, bildiğim kadarıyla, maven ile de kullanılabilir, ancak varsayılan olarak dikiş-gen Apache Ant'i kullanır. JBoss Forge (dikiş-geninin değiştirilmesi ve aslında daha çok Spring Roo gibi) Maven'i kullanıyor.
  • Spring Roo, Spring framework'ü temel alırken JBoss Seam, tüm Java EE 5 yığınına dayanıyor (Seam 3, Java EE 6 yığınını kullanacaktır). JBoss Seam ve dikiş-gen aracının varsayılan olarak EJB 3.0'ı kullanacağını unutmayın, ancak bu isteğe bağlıdır ve JBoss Seam ve dikiş-gen aracıyla bir EJB çözümü tercih etmeyebilirsiniz.
  • JBoss Seam (dikiş-gen ile) JBoss Seam özel sınıflarını genişleterek oluşturulan sınıflara temel işlevsellik eklemek için temel OO mirasını kullanır. Bu, JBoss Seam (ve dikiş-gen) özel sınıflarına çalışma bağımlılığı ekler. Spring Roo, hem düz Java kaynak dosyalarını (Yay ile ilgili sınıfları genişletmeden) hem de bu sınıflara açıklama ekleyerek tamamen farklı bir yaklaşım seçer. Oluşturulan Java kaynak dosyalarının yanı sıra, Spring Roo ayrıca oluşturulan kaynak kodu ve ek açıklamaları içeren AspectJ özel dosyaları olan bir veya birkaç sözde arası tür bildirim (ITD) dosyası oluşturur. Bu ITD dosyaları, derleme süresinden sonra oluşturulan sınıf dosyalarına tamamen şeffaf şekilde dokunulacak ve bu nedenle çalışma zamanı bağımlılığı dayatmayacaktır.
  • Seam tarafından üretilen dosyalar sizin tarafınızdan güncellenebilir (ve olacak), ancak dikiş-gen ile dosyaları yeniden oluşturmanız gerekiyorsa, el ile yaptığınız değişikliklerin üzerine yazılacaktır, çünkü Seam-gen tarafından oluşturulan dosyalar tarafından yapılan değişiklikleri yapacaktır. Spring Roo'nun ITD'lerle olan yaklaşımı nedeniyle, ITD dosyalarındaki oluşturulan kaynak kodu geçersiz kılan Java kaynak dosyasında değişiklikler yaparsınız. Bu, Spring Roo'nun ITD'leri, Java kaynak dosyasında bulunan ve ardından değiştirilmeden yapılan manuel değişikliklerden kurtarması için yeniden yaratmasını mümkün kılar.
  • Dikiş-gen kullanımı, projeyi başlangıçta kurmak ve bir başlangıç ​​yapmak için tek seferlik bir üretim / kullanıma daha yatkındır, oysa Spring Roo projenin ömrü boyunca kullanılmaktadır.
  • Spring Roo bir projeden çıkarılabilir, artık Spring Roo'ya bağımlılığı olmayan tamamen çalışan bir proje bırakır ve elbette istediğiniz şekilde inşa edilebilir ve genişletilebilir. Dikiş-gen yardımcı programı böyle bir işlev sunmaz, ancak dikiş-gen durumunda elbette dikiş-geninin kendisinden asla değil, belirli bir JBoss Seam paketine (çerçeve olarak adlandırılır) bağlı olmazsınız.
  • JBoss Seam (dikiş-gen ile) temel olarak JSF'yi web çerçevesi olarak kullanmak için planlanmıştır, Spring Roo ise web çerçevesi olarak Spring MVC ve / veya GWT'ye odaklanmıştır. JBoss Seam'in kendisi de Wickete için iyi bir destek, ama dikiş-gen aracıyla değil. Spring Roo'nun ayrıca bir Flex eklentisi vardır ve diğer web çerçeveleri için daha fazla eklenti toplulukta yaratılır, ancak hepsi hala Spring MVC ve GWT'ninki kadar iyi değildir.
  • Dokümantasyon hem JBoss Seam hem de Spring için harika, ama Spring Roo ve dikiş-gen aracı için daha gelişmiş belgelere sahip değiller. Bu arada Spring Roo da komut satırı kabuğunda çok faydalı ipuçları sunuyor.
  • JBoss Seam yaklaşımı için IDE desteği, Spring Roo yaklaşımından daha iyidir. Her iki çözüm de Eclipse tabanlı özel bir IDE'ye ve eklentilere (Spring Roo için SpringSource Tool Suite ve JBoss Seam için JBoss IDE) ve diğer tüm büyük IDE'lere (Netbeans en IntelliJ) temel çerçeveler için büyük bir destek var, ancak Eclipse IDE'leri yok. IntelliJ IDE için tam olarak emin değil) Spring Roo tarafından üretilen ITD'ler için iyi bir desteğiniz yok. Bu, derlemede bir sorun değildir, ancak bu IDE'lerde intellisense ve kod tamamlama ile ilgili işlevlerle ilgili sorunlar sağlar.

Bu iki büyük ürün arasında elbette çok daha fazla farklılıklar olsa da ve bu projelerin test edilebilirliği, öğrenme eğrisi ve geleceği gibi önemli şeylere bile değinmedim, umarım yukarıdaki mermiler bu iki çözümü düşünen insanlara zaten yardımcı olabilir. en azından biraz daha kurulu bir karar vermek. Bir karar vermenin en iyi yolunun, her iki yaklaşımda da bir kavram kanıtı oluşturmak ve hangi en iyi suitleri görmeniz gerektiğini tekrar vurgulamak isterim.

Kolay ve hızlı bir karar vermenizi sağlayan ana noktalar, Spring stack veya Java EE yığını, IDE desteği, Web Çerçevesi ve çözümün 'yetişkinlik' seçenekleri arasında seçim yapabiliyor. Eğer Bahar yığına çok aşinaysanız (ki sanırım, Grails'den geldiğinizi görüyorsanız), Spring Roo'ya gidin, JSF dahil Java EE yığınına aşina olmak için biraz zaman kaybedebilirsiniz. (tabii ki bu, projenizin büyüklüğüne bağlıdır, ancak çok büyük bir proje olmadığı varsayılarak, yeni tekniklerin öğrenilmesinin etkisi, tek bir proje için çok büyük olabilir). Eclipse'i kullanamazsanız veya kullanmak istemezseniz ve gerçekten bu konuda tutkuluysanız, JBoss Seam'in daha iyi bir çözüm olabileceğini düşünüyorum. Eğer JSF veya Wicket'i kullanmak istiyorsanız, JBoss Seam'e gidin, Spring MVC veya GWT'yi kullanmak istiyorsanız, Spring Roo'yu kullanın (diğer web çerçeveleri için muhtemelen hangisini seçtiğiniz önemli değildir). daha iyi bir çözüm). Ve eğer 'yetişkinlik' ana karar noktanızsa, sanırım JBoss Seam'i daha iyi kullanacaksınız. Her ikisi arasında karar vermek gerçekten zor olabilir, ama en azından her iki çözümün de gerçekten harika olduğunu ve her iki şekilde de size çok yardımcı olacağını bilin.

Bu arada, gelecek vaat eden proje ile mevcut dikiş-gen çözümünün yakın gelecekte değiştirileceğinden JBoss Forge projesine dikkat etmeyi unutmayın.


51
2017-12-07 13:35



Teşekkürler. Çok detaylı ve tarafsız bir cevap. VMWare'de AspectJ ve Groovy araç desteğinde çalışan bir geliştirici olarak, Spring Roo ve Grails arasında daha fazla karşılaştırma yapmayı umuyordum. Ancak, bahsettiğinizden beri, STS'de Spring Roo için bulduğunuz takım desteğinin eksiklikleri hakkında biraz daha ayrıntılı bilgi alabilir miydiniz? - Andrew Eisenberg
Teşekkürler Andrew. Son zamanlarda Grails'i kullanmadığım için, yukarıdaki yaklaşımda bu yaklaşımı dikkate almadım. Yine de Grails'i bir gün Spring Roo ve Seam ile karşılaştırmak istiyorum, bu yüzden belki yeni bir yorum veya cevap ekleyeceğim. - Tim
IDE desteğiyle ilgili olarak, STS'nin Spring Roo'ya verdiği destekten fazla bir şey (hiç bir şey yapmıyorsa) olmadığını sanmıyorum. Benim düşünceme göre, Spring Roo için IDE desteğinin JBoss Seam için biraz daha az olmasının nedeni, NetBeans gibi diğer büyük IDE'lerin AspectJ için iyi desteğe sahip olmaması ve dolayısıyla Roo tarafından üretilen ITD'lerle ilgili sorunların olmasıdır. Otomatik tamamlama / intellisense ile sorunlara neden olur. Bu nedenle destekteki farklılık işlevsellikte değil, farklı IDE'lerde. - Tim


Sadece Forge -> http://forge.jboss.org

Bir acemi iseniz, kalıcılık, testler ve güvenlik ile bir web uygulaması olacak. Ve dahası.

Java'yı biliyorsanız, yukarıdakilerle aynı olacaksınız ve iyi uygulamaların nasıl yapılacağına dair inanılmaz bir bilgi kaynağı olacaksınız: Kaynak kodu ve Forge tarafından oluşturulan kaynaklar. Java EE (CDI, Validasyon, JSF), maven, JPA, fayans, EJB ... ve daha pek çok şey hakkında çok şey öğrenebilirsiniz.


4
2018-01-16 19:41





Sadece Roo.

Bir acemi iseniz, kalıcılık, testler ve güvenlik ile bir web uygulaması olacak. Ve dahası.

Java'yı biliyorsanız, yukarıdakilerle aynı olacaksınız ve iyi uygulamaların nasıl yapılacağına dair inanılmaz bir bilgi kaynağı olacak: Roo tarafından üretilen kaynak kod ve kaynaklar. Bahar (çekirdek, güvenlik, MVC), maven, JPA, fayans, mesajlaşma hakkında çok şey öğrenebilirsiniz ... Ve daha pek çok şey.


1
2017-11-16 19:58