Session Beans und EJB3 vs Frühling
Ich war neugierig über die Möglichkeiten von Sessions Beans in EJB 3 und ob Sie ersetzt werden kann, die in einem typischen mid-scale enterprise-Anwendung mit Spring.
Fand ich diesen Artikel:
http://drag0sd0g.blogspot.com/2010/01/session-bean-alternative-spring.html
die Folgendes besagt: "Wegen der starken Nutzung von Anmerkungen,
Sie können ziemlich viel zu vermeiden "XML-Hölle" mit EJB 3; das gleiche kann nicht gesagt werden, der Frühling.
Darüber hinaus, denn es ist ein integraler Bestandteil der Java-EE-standard, der EJB-container
nativ integrierte Komponenten wie JSF, JSP, servlets, die JTA-Transaktion
manager, JMS-Anbieter, und JAAS-security-Anbieter der Ihrem Anwendung-server. Mit Feder, Sie haben sich sorgen zu machen, ob Sie Ihren application server unterstützt das framework mit diesen systemeigenen Komponenten und andere high-performance-features wie clustering, load balancing und failover. Wenn Sie nicht besorgt über solche Dinge, dann ist der Frühling nicht eine schlechte Wahl"
Stimmen Sie dieser Aussage zu? Die Stateless Sessions-Beans verwendet werden, um als eine sehr mächtige enterprise-Technologie durch die Bündelung und management-Fähigkeiten. Meine Frage ist: Wann ist es wirklich notwendig, verwenden EJB 3 anstelle der oder zusätzlich zur Feder (unter der Annahme einer unternehmenskritischen Anwendung in einem großen Unternehmen)?
- Siehe stackoverflow.com/questions/68527/...
- "Wegen der starken Nutzung von Annotationen, man kann ziemlich viel zu vermeiden "XML-Hölle" mit EJB 3; das gleiche kann nicht gesagt werden, der Frühling", Das ist nicht wahr, Sie können konfigurieren, Frühling, mit Anmerkungen und java-code nur, aber dadurch, dass Sie die Kopplung Ihrer Anwendung eng an das spring framework und verlieren Sie die erstaunliche bean-management-Funktionen der Eclipse-Spring IDE. XML ist nicht die Hölle mit dem Frühling, wenn Sie die richtigen Hilfsmittel verwenden.
- "Wegen der starken Nutzung von Annotationen, man kann ziemlich viel zu vermeiden "XML-Hölle" - Sie haben jetzt Annotation der Hölle statt.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Sieht aus wie ein weiteres Java EE vs. Frühling posten...
EJB/Java EE und Spring sind jetzt zwei Reifen, wettbewerbsfähige Java-basierte Technologie-stacks. Oft gibt es keinen Grund, die Dinge zu komplizieren, und mischen Sie sich. EJB tatsächlich gelernt und viele Ideen aus Spring et al.
Keiner von Ihnen fährt Sie in die XML-Konfiguration, die Hölle. Beide sind ziemlich einfach, um loszulegen mit, zumindest mit den ganz grundlegende Dinge.
Frühling ist mehr als nur IoC/SOA/Transaktionen. Es ist mehr wie eine " toolbox - es ist bereit, sich zu integrieren, oder direkt, Rahmenwerke für ORM und Transaktionen, web/MVC, Sicherheit, Timer/Planung etc. Sie können wählen Sie genau die Stücke, die Sie brauchen. Du bist nicht gezwungen, einen Behälter (Sie können verwenden Sie es in Ihrem standalone "desktop" - app).
EJB ist Teil von Java EE stack. Es ist gut, die standard. Es ist nicht so breit, flexibel, wie der Frühling, aber es ist per definition von allen unterstützt Java EE-Container.
Ich ziehe den Frühling für die Freiheit und einen Schritt Voraus zu sein.
Ich glaube nicht, dass es gibt viele Fälle, wenn die Verwendung von EJB 3 statt der Feder ist absolut notwendig, aber es gibt Fälle, bei Verwendung von EJB 3 wäre deutlich einfacher. Wie der Artikel sagt, die wichtigsten Vorteile von EJB ist die integration mit den diversen anderen JEE-Technologien und-wie von EJB 3, Enterprise Beans sind viel einfacher zu schreiben als Sie waren in vorherigen Versionen der spec.
Den klassischen Grund für den Einsatz von EJB über POJOs oder anderen middleware-Technologien ist Transaktionen. Wenn Sie Ihre business-Logik muss transaktional sein, dann EJB bietet einfache, deklarative transnationalen Abgrenzung und nahtlose integration mit JTA über die container. Während der Artikel suggeriert, dass die Unterstützung für clustering, load balancing und performance-management ist ein Vorteil, dies ist sehr stark abhängig von Ihrer Wahl JEE application server.
Ich würde sagen, der wichtigste Faktor bei der Entscheidung, ob Spring oder EJB 3 ist dein container. Wenn Ihr Ziel-container ist ein komplett JEE 5+ konformer application server und Sie brauchen Unterstützung für Dienste wie Transaktionen oder messaging-dann EJB 3 ist die offensichtliche Wahl. Wenn, jedoch, Sie brauchen nicht zu integrieren, mit anderen JEE-Technologien oder für die Bereitstellung in eine Licht-Gewicht-app-server mit EJB-würde nur unnötigen Aufwand verursachen.
Wie kann jemand denken, EJB3 definiert ein Datenmodell mit einer Reihe von java-Annotationen, die sich über mehrere Klassen überlegen ist, Überwintert einfache Modell-definition syntax ist mir schleierhaft.
Seine ein Wartbarkeit Alptraum. Warum hast du eine Verknüpfungstabelle? Es kann definiert werden fast überall in die code-Basis. Einige junior-Programmierer spielt mit den Anmerkungen und jetzt Ihre java-Klassen sind out-of-sync mit der aktuellen Datenbank.
Wurde eine performance-Probleme (und Sie werden). Nicht nur haben Sie die klassischen Hibernate "ich weiß nicht, was SQL ist es mit" Sie haben auch die "ich weiß nicht, warum der Tisch wurde gebaut wie das" problem.