Vraag EJB 3.1 of Spring 3 .. Wanneer kiezen welke?


EJB heeft veel verbeteringen bereikt in 3.x-versies, Spring wordt ook vaak gebruikt en versie 3 is een goed alternatief.

Er zijn veel artikelen op internet, maar geen exacte vergelijking over ejb3x versus lente3x. Heb je ideeën over hen, in voorbeelden uit de echte wereld, welke is beter tegen welke voorwaarden?

We willen bijvoorbeeld db en server van elkaar scheiden, wat betekent dat onze applicatie op een server staat, onze database op een andere server staat .. EJB remoting versus Cluster4Spring enz.?

Is alles doen @Annotation altijd goed? configuratie nooit nodig?


39
2017-08-16 09:30


oorsprong


antwoorden:


Voor uw geval waarin de applicatie op één server draait en de database op een andere wordt uitgevoerd, is de keuze tussen EJB en Spring niet relevant. Elke platform ondersteunt dit, of het nu een Java SE-applicatie is, een eenvoudige Servlet-container zoals Tomcat of Jetty, PHP, Ruby on Rails of wat dan ook.

Daarvoor hebt u geen expliciete remoting nodig. U definieert alleen een gegevensbron, geeft de URL op waar uw DB-server woont en dat is het.

Dat gezegd hebbende, maken zowel EJB als Spring Beans het gemakkelijker om met databronnen te werken. Beide helpen u bij het definiëren van een gegevensbron, het injecteren in bonen en het beheren van transacties die daarmee zijn verbonden.

Van de twee is EJB (en Java EE in het algemeen) lichter en houdt meer vast aan het conventieconfiguratieprincipe. De lente vereist meer breedsprakigheid om dezelfde dingen te krijgen en hangt sterk af van XML-bestanden die snel heel groot en onpraktisch kunnen worden. De keerzijde van de medaille is dat de lente minder magisch is en dat je je meer in controle kunt voelen na alles wat je wilt uit te spellen.

Een ander probleem is de manier waarop EJB en Spring worden ontwikkeld.

EJB is gratis (zoals in gratis bier), open-source en niet-gepatenteerd. Er zijn implementaties van EJB gemaakt door non-profit organisaties (Apache), open source bedrijven (Redhat / JBoss) en diep commerciële closed source enterprises (IBM). Ik zou persoonlijk de laatstgenoemden, maar elk zijn eigen vermijden.

De lente daarentegen is gratis en open-source, maar sterk gepatenteerd. Er is maar één bedrijf dat Spring maakt en dat is Springsource. Als je het niet eens bent met Rod, dan heb je pech voor je. Dit hoeft niet per se slecht te zijn, maar het is een verschil waar je je misschien bewust van wilt zijn.

Is alles doen @Annotation altijd goed? configuratie nooit nodig?

Het is eigenlijk een eindeloos debat. Sommigen beweren dat XML moeilijk te onderhouden is, anderen beweren dat annotaties een anderszins puur POJO-model vervuilen.

Ik denk dat het annoteren van een boon als een EJB stateless bean (@Stateless) of een JPA-entiteit (@Entity) netter is gedaan met behulp van annotaties. Hetzelfde geldt voor de injecties met @EJB of @Inject. Aan de andere kant geef ik er de voorkeur aan dat JPQL-query's in XML-bestanden voorkomen in plaats van annotaties, en injecties die pure configuratiegegevens (zoals een max-waarde voor iets) vertegenwoordigen ook in XML.

In Java EE kan elke annotatie ook in XML worden opgegeven. Als zowel de annotatie als het XML-equivalent aanwezig zijn, overstemt de XML de annotatie. Dit maakt het echt handig om te beginnen met een annotatie voor de standaardcase, maar deze later via XML op te heffen voor een specifieke use-case.

De huidige voorkeur in Java EE lijkt meer te liggen in de richting van (eenvoudige) annotaties in combinatie met een grote hoeveelheid conventie ten opzichte van configuratie.


56
2017-08-17 13:08



De echte vraag die je zou moeten stellen is CDI / EJB of lente


14
2017-08-27 22:53



Het is vaak niet Spring vs EJB, maar Spring vs Java EE. EJB zelf is te vergelijken met Spring Beans. Beiden zijn een soort van beheerde bonen die in een container lopen (de EJB-container resp. Spring-container).

Over het algemeen zijn de twee technologieën vrij gelijkaardig. Reza Rahman deed een geweldige vergelijking tussen de twee een tijdje terug.


6
2017-08-17 09:31



EJB's zijn voordeliger vanwege standaardisatie. Als je met een lichtgewicht applicatie werkt denk ik dat het goed gaat met Spring, maar als je verwacht dat je applicatie groot zal zijn en veel toegang tot het geheugen en gegevensverbindingen zal vereisen, zou je kunnen overwegen om je ontwikkeling met EJB's te starten. De belangrijkste reden voor clustering en taakverdeling is ingebouwd in het EJB-framework.

In een EJB-omgeving, wanneer een EAR ('E'nterprise' AR'chive) wordt ingezet, kan het worden ingezet met meerdere EJB-bonen die elk een specifiek doel kunnen hebben. Stel dat u een boon schreef voor gebruikersbeheer en een andere boon voor productbeheer. Misschien vindt u op een dag dat uw services voor gebruikersservices uw productservices overschrijden en dat u uw gebruikersboon naar een andere server op een andere computer wilt verplaatsen. Dit kan eigenlijk in runtime worden gedaan zonder uw code te wijzigen. Bonen kunnen worden verplaatst tussen servers en databases, zodat clustering en load / data-balancering mogelijk is zonder dat dit gevolgen heeft voor uw ontwikkelaars of uw gebruikers, omdat de meeste ervan kunnen worden geconfigureerd op implementatieniveau.

Een andere reden om een ​​norm te ondersteunen is te weten dat de meeste grote externe leveranciers dit waarschijnlijk zullen ondersteunen, wat resulteert in minder problemen bij de integratie met de nieuwe standaard / service / technologie - en laten we eerlijk zijn, die komen eruit als nieuwe smaken ijs. En als het een openbare specificatie is, kunnen nieuwe startende bedrijven of aardige ontwikkelaars een open-source versie maken.

http://www.onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html

Het is zeer ongelukkig dat zelfs de meest intelligente ontwerpers of programmeurs niet kunnen voorspellen welke van hun functies al dan niet worden omarmd door de ontwikkelgemeenschap, wat de belangrijkste reden is dat software opgeblazen raakt ... Java EE is dat zeker!


6
2017-11-12 19:48



Kies een van de twee, maar niet allebei.

Mijn persoonlijke voorkeur is Lente. Ik heb de afgelopen zes jaar met veel succes projecten gebruikt. Het is zo solide als elke software die er is.

Lente kan werken met EJB's als u ervoor kiest ze in uw app te hebben, maar ik geloof niet dat het omgekeerde waar is.

Ik zou afzonderlijke fysieke machines aanbevelen voor web-, app- en databaseservers als je het kunt betalen.

Spring kan werken met verschillende opties voor remoting, waaronder SOAP- en REST-webservices. Een vergelijking van Lentebonen met EJB valt buiten het bestek van deze vraag. Ik zie niet wat het te maken heeft met je implementatie. Als u Spring POJO-services gebruikt, bevindt deze zich in het geheugen in plaats van een andere netwerkhop zoals externe EJB's. Denk aan Fowler's wet van gedistribueerde objecten: "Do not". Introduceer latentie alleen met goede reden.


3
2017-08-16 09:34



EJB 3.1 is de beste terwijl het de standaard is voor Java 6 EE-toepassingen.

Spring ondersteunt nog steeds geen Java 6 CDI (las) maar hangt ook nog steeds sterk af van XML-configuratie. EJB 3.1 is krachtig en slim.

Ik denk dat Spring 3.1 geen XML-configuratie nodig heeft. U hebt de mogelijkheid om annotaties te gebruiken voor configuratie.


2
2018-04-16 06:54



Ik noem het testen van eenheden hier. In een gewone webapplicatie (controller-> service-> data -> ...-> weergave) bieden EJB en Spring beide hetzelfde resultaat, maar de lente biedt eenvoudiger testen.

In mijn bescheiden ervaring is de manier waarop je je ontwikkelt in een aantal opzichten anders:

  • Eenheidstest (voorjaarswinsten). In het voorjaar is het behoorlijk strak vooruit gedaan, terwijl je in ejb Arqullian met ShrinkWrap (sic!) Moet gebruiken dat bij elke build traag werkt.
  • Persistentie (ejb wint). In de lente is er strijd omheen, d.w.z. google "hoe autowire persistentie in entiteit luisteraar" http://bit.ly/1P6u5WO
  • Configuratie (ejb wint). Toen newbie uit ejb kwam, werd ik verrast door een overvloed aan aantekeningen en .xml-bestanden.

2
2017-08-05 15:21