.NET - gegen EJB

Definition der Begriffe ist wichtig

Wenn dabei die Vergleiche, die definition von Begriffen ist wichtig. EJB ist ein
- Komponenten-Modell. Es definiert die Persistenz -, Transaktions -, remoting, Aktivierung und
die Sicherheitsfunktionen (und vielleicht andere) für Komponenten, die den Betrieb in
der Behälter.

Können Sie Blick auf vergleichbare Technologien .NET, wenn es das ist, was Sie sind
nach den technischen Fähigkeiten des Komponentenmodells.

Auf der anderen Seite, einige Leute benutzen "EJB" als ein Begriff, der lose siehe
J2EE - (oder Java EE?). In dem Fall bezieht es sich nicht nur, um ein Komponenten-Modell, aber
eine Reihe von verwandten Java-Technologien, in der Regel verbunden zu server-side
Anwendungen, einschließlich ein-Komponenten-Modell. Diese könnten sogar toolsets, die natürlich
nur peripher mit dem Komponenten-Modell. Wenn , dass wird die
Vergleich, dann ist es mehr treffend beschrieben als "J2EE vs. .NET".

Immer noch andere Leute vielleicht mit einem noch unschärfer definition für EJB zu
gehören Dinge wie web-services-Fähigkeit, REST/XML-Kommunikation, oder
andere Sachen, die strikt außerhalb der Java-EE-oder EJB richtige. In anderen Worten, wenn Sie sagen "zu vergleichen, EJB zu .NET" meinen Sie tatsächlich zu vergleichen "Server-side Java-Plattformen auf server-Seite .NET". Das letztere erscheint mir als viel mehr den praktischen Vergleich zu machen, als den Vergleich, sagen wir, Modelle.

Wenn du die Vergleiche, es ist wichtig, klar zu sein über genau das, was
der verglichen wird.

EJB - Komponentenmodell

In EJB definieren Sie ein Objekt und markieren Sie es als eine Session Bean oder eine Entity
Bean. Es gibt auch die späte Zugabe von Message-Driven Bean. Drei
Aromen von Komponenten in EJB. Die Session-Bean wird die Aktivierung - wie es
begonnen hat und möglicherweise "passiviert" in Zeiten hoher Ressource
Streit auf dem server/container. Der SB bekommt auch Sicherheits-und
remoting-Dienste.

Die grundlegende Idee ist, ein Objekt definieren und dann anfügen von Attributen,
entweder durch den deployment-descriptor oder durch in-code-Attribute,
die analog für die aufgerufen wird, Anmerkungen in Java.

Ist die nächste Sache, eine EJB-Session-Bean ist eine .NET-Objekt. In jedem .NET
Anwendung, können Sie markieren ein Objekt mit Transaktion Attribute, nur
wie ein EJB-SB. Sie können es remotefähige, wenn Sie wie, mit .NET
Remoting und mehr Attribute. Außerhalb von COM+, es gibt keine Passivierung Technologie in
.NET; .NET einfach ignoriert pooling als eine grundsätzlich interessante Sache zu tun
in-memory-Objekte, und als Ergebnis, es ist kein Konzept zu tun, Aktivierung/Passivierung .NET wie es ist mit EJB.

sidebar #1: das ist nicht ganz richtig. In .NET, die Workflow-Funktion bietet eine Möglichkeit, lang andauernde Aktivitäten, die können und werden passiviert und re-aktiviert. Aber, Workflow ist eine deutliche Metapher von "server-side objects" oder "services", die den Mittelpunkt der meisten server-side application-Architekturen, nutzen .NET.

sidebar #2: Es verwendet zu sein, dass die Entwickler von server-side-Plattformen dachte, jeder würde wollen, verwenden Sie die Objekt-pooling, um effizienter zu sein. Nun, es stellt sich heraus, dass die JVM und .NET CLR sind schnell genug auf die Erstellung von Objekten, und der Speicher ist groß genug, dass im Allgemeinen die Objekt-pooling ist nicht von praktischem nutzen. Es ist nicht mehr interessant für den Allgemeinen Fall, obwohl es immer noch zahlt gute Dividenden für teure Gegenstände wie Datenbank-verbindungen.

Als mit EJB,.NET können Sie die Sicherheit
Attribute auf ein Objekt, um es zu ermöglichen zu laufen oder nicht laufen auf der Basis der
Identität des Anrufers oder andere "Beweise".

Entity-Beans sind ein anderes Tier. Während persistence und remoting kann
kombiniert werden in den meisten praktischen Reiseführer, die Empfehlung ist, dass ein
- entity-bean nicht über eine remote-Schnittstelle. Stattdessen die Empfehlung für eine
session-bean aufrufen einer entity-bean. Also lasst uns einfach betrachten die EB ist als
persistente Objekte.

In .NET gibt es eine Reihe von alternativen. LINQ-to-SQL gibt eine
option - mit ORM-Persistenz und Dienstleistungen. Die ADO.NET Entity
Rahmen ist vielleicht eine vergleichbare Technologie. Natürlich auch alle anderen
Dienstleistungen in .NET - Transaktionen Sicherheit und remoting etc. - kann auch sein
auf ein Objekt angewendet werden, verwenden ADO.NET Entity Framework oder LINQ.

Auf der anderen Seite, je nachdem, wo Ihr Schwerpunkt liegt in der EJB
Regenschirm, es gibt vielleicht bessere Vergleichswerte. Wenn Sie verwenden in Erster Linie für EJB
remoting - und mit dem Aufkommen von REST -, SOAP-und andere leichte
Protokolle, fast niemand tut dies mehr, soweit ich das beurteilen kann -, dann eine
besser vergleichbar .NET WCF.

Schließlich, die vergleichbar mit EJB MDB sind .NET-Komponenten in der Warteschlange.

EJB Remoting

Gibt es einige gemeinsame Aspekte, die auf alle diese Arten von EJBs - wie remote-interfaces. Eigentlich die meisten Architekten empfehlen, dass Sie nicht verbreiten Sie Ihre EJBs. In anderen Worten, Sie entmutigen die Menschen von der Nutzung der remoting-Aspekt so Häufig diskutiert. Stattdessen wird ein servlet sollte aufrufen, die ein EJB -, lokale, eher als Berufung auf eine remote-Maschine. Dies ist Fowler ' s Erstes Gesetz: nicht verteilen Sie Ihre Objekte.

Auf der anderen Seite, manchmal müssen Sie.

WCF ist das Kommunikations-framework innerhalb .NET, und das ist der Aspekt in .NET am ehesten vergleichbar mit EJB remoting. Aber Sie sind nicht äquivalent. WCF ist eine sehr Allgemeine Zweck-Rahmens für die remote-Kommunikation, unterstützt sync und async, mehrere Protokolle und extensible transport-und Kanal-Modell, während EJB remoting ist ziemlich begrenzt.

Ist ab EJB-der richtige Ansatz?

EJB gar nichts sagen (soweit ich weiß) über web-services oder REST,
oder-management oder leichten Rahmen, oder auch HTML-oder Entwickler-tools. Starten
Vergleich mit "EJB vs leer" künstlich " beschränkt die Diskussion
ein wenig. Es frames, die Diskussion in einer Weise, die möglicherweise nicht
optimal sind.

Es gibt nichts in der EJB zu behandeln, zum Beispiel eine HTML-Seite, die Metapher.
Die bekommst du in servlets oder einem seiner Vettern (portlets, etc.), von denen einige in J2EE richtige. Aber streng genommen, ist die HTML-Ausgabe ist nicht bedeckt in EJB.

Nun, vielleicht Sie beabsichtigen, eine der umfangreicheren Definitionen von
EJB. Zu diesem Zweck, J2EE bietet nun web-services in der Spezifikation. Aber auch so, ich bin mir nicht sicher, wie relevant es ist, zu erwägen, die Skillung, mit der Vielzahl von add-on Java-basierte frameworks für SOAP-web-services und REST.

Ebenso, wenn Sie möchten, zu berücksichtigen UI-Funktionen wie portlets, servlets, AJAX und vergleichen Sie mit der .NET-äquivalente, dann ist Sie umgezogen sind, auch außerhalb des EJB-und J2EE-und in server-side Java im Allgemeinen.

Wird es zurück zu meinem früheren Punkt - klar und präzise in deinen eigenen Verstand über das, was
Sie sind daran interessiert, zu prüfen oder zu vergleichen.

Den EJB-und J2EE-Vorgaben waren ehrgeizig - der Versuch zu definieren, die Rahmenbedingungen für die Anwendungen der server-Seite. Aber es gab immer eine zeitliche Verzögerung zwischen dem, was Entwickler tun, was die Skillung war zu sagen, und was die Verkäufer waren liefert. Weißt du, vielleicht gab es eine 1-Jahres-lag zwischen der Fertigstellung einer neuen version der J2EE-Spezifikation und dem release einer kompatiblen server von IBM.

Weil dieser es endete als eine Art künstliche, nach-der-Tatsache. Die Skillung war die Beschreibung der Dinge, die Menschen bereits getan haben. Dinge, wie der Frühling kommen Sie heraus und J2EE nicht sagen nichts über Sie. Für die längste Zeit, J2EE, hatte nichts zu sagen über den REST-oder Web-services oder AJAX. (Auch jetzt, sagt es nichts über AJAX? Ich weiß es nicht.)

Angesichts der Entfernung zwischen der Theorie von der Skillung und der Realität der Praxis durch die Entwickler, ein besserer Ansatz könnte sein, zu identifizieren, die den Anforderungen der Anwendung, und
dann vergleichen Sie die EIGNUNG von EJB und andere Verwandte Technologien, um die
apps, die Sie erstellen möchten.

In anderen Worten - angenommen, eine Ihrer Voraussetzungen ist, dass die app geliefert werden, über den browser, und es wird die Reaktion von AJAX. In diesem Fall sind Sie gehen zu müssen, zu prüfen, jQuery, und das ist nicht überall abgedeckt in J2EE oder EJB. AJAX-frameworks verfügbar in den verschiedenen Produkten (sowohl Java als auch .NET). Zum Beispiel Visual Studio verwendet jQuery für das ASPNET-AJAX-Zeug. Aber das festhalten an der specs Art findet dieses Zeug.

Bottom Line

Die bottom line ist, jede app, die Sie mit EJBs gebaut werden kann, in
.NET, und Umgekehrt.

Ich denke, dass ein Vergleich wie "EJB-vs .NET" können Interessierte als eine Akademische
Diskussion, aber wenn Sie möchten einen praktischen Einblick in das, was Technologie
verwenden Sie, wo Sie sind, dann müssen Sie denken, ein wenig anders.

Müssen Sie identifizieren und priorisieren Anforderungen, wie Geschwindigkeit des
Entwicklung, Kosten für die Bereitstellung, Mechanismus, Implementierung, tool-support, deployment-Plattform-Unterstützung,
language-support, performance, UI Aussehen, UI-Optionen, etc. Dann Wiegen die Optionen vor, die priorisiert
Liste.

InformationsquelleAutor der Antwort Cheeso

viele der EJB-Funktionalität ist bereits nativ in .Netto (d.h. Datenbank-Transaktion), aber es ist die enterprise services-namespace bietet eine Menge Funktionen.

InformationsquelleAutor der Antwort Russ Bradberry