EJB3 Business Delegates

Question

Gibt es einen Grund, Delegat zu machen, wenn Sie EJB3 verwenden? Weil der einzige wirkliche Vorteil, den ich von Delegaten sehe, ist, dass es erlaubt, Lookup- und Zugriffsdetails der EJB-Architektur zu verbergen. Nun, es bietet auch eine Entkopplung, aber es ist meist unbenutzt, imho. Mit EJB3 haben wir eine Injektion, also kann ich jetzt einfach eine Variable mit @EJB Annotation erstellen und sie so verwenden, wie sie ist. Benötige ich noch Delegierte? Nimmt diese Injektionsressource zu? Ich meine, wenn ich es in der Anfrage von JSF verwaltete Bohnen verwende, ist es immer noch besser Delegierte zu verwenden, nur um diese Injektionsanrufe zu verringern?

Vielen Dank!

Answer 1

Lassen Sie uns rekapitulieren die Kräfte des ursprünglichen business delegate pattern:

• Presentation-Tier-Kunden benötigen Zugriff auf Business-Services.
• Verschiedene Clients, z. B. Geräte, Webclients und Thick Clients, benötigen Zugriff auf den Geschäftsservice.
• APIs für Unternehmensservices können sich ändern, wenn sich die Geschäftsanforderungen ändern.
• Es ist wünschenswert, Kopplung zwischen Präsentationsschicht-Clients und dem Business-Service zu minimieren, so dass die zugrunde liegenden Implementierungsdetails des Dienstes, wie Lookup und Zugang zu verstecken.
• Clients müssen möglicherweise Caching-Mechanismen für Business-Service-Informationen implementieren.
• Es ist wünschenswert, den Netzwerkverkehr zwischen Client- und Geschäftsdiensten zu reduzieren.

Alle diese Kräfte sind heute noch relevant - sie sind in jedem Projekt nicht notwendig vorhanden sind, aber konnte.

Die wichtigste Änderung besteht darin, dass wir den Geschäftsdelegaten nicht benötigen, um die Kopplung zu minimieren (die in Kursivschrift). Die Abhängigkeitsinjektion löste das Problem der Suche und des Zugriffs.

Ich mag die analysis from Adam Bien: einer der Punkt über die Kopplung, die natürlich noch nicht gelöst ist, sind Ausnahmen. Ausnahmen sind jetzt deaktiviert, aber immer noch vorhanden. Ob der Kunde von EJB-Ausnahmen vollständig abgeschirmt werden soll oder nicht, hängt wiederum von den im Projekt vorhandenen Kräften ab.

In dem Fall, dass das Business-Delegate-Muster eingeführt wurde, um das Problem von Lookup und Zugriff zu lösen (was ich für viele Projekte vermutete), brauchen wir es effektiv nicht mehr. Wenn der Geschäftsdelegierte aus anderen Gründen gemeint war, kann es immer noch sinnvoll sein.

PS: aus eigener Erfahrung, war Ressource Injektion nie ein Leistungsproblem (I als die Millisekunde ein ernsteres Performance-Problem an anderer Stelle immer hatte die für die Injektion genommen :)

Answer 2

Business-Delegierten waren nur ein Hack zu verstecken ganze Kludis mit JNDI-Lookups und allen damit verbundenen Aufräum- und Fehlerbehebungen. Die Ressourceninjektion kam über Gavin Kings Seam in J2EE, was im Prinzip den so wenigen Layern wie möglich und der Konfiguration in einem einzigen Platz folgt. Also vergiss diese alten Muster und benutze einfach normale OO-Gedanken.

Meine 2 Cent.

Answer 3

Nun, eigentlich verstehe ich diese Punkte nicht ganz.

Präsentations-Tier-Clients benötigen Zugriff auf Business-Services.

Presentation Tier im Falle von JSF ist Managed Bean, nicht wahr? Wenn es so ist, dann wird dieses Problem durch Injektion gelöst. Recht?

Verschiedene Clients wie Geräte, Web-Clients und Thick Clients, müssen Zugang zum Business-Service.

Ich habe keine Geräte und dicke Clients. Und was ist Webclient? Ist es nicht die gleiche Präsentationsebene von oben? Wenn es so ist, haben wir die gleiche Situation wie oben. entwickeln

Business-Services-APIs können als Geschäftsanforderungen ändern.

Ich kann nicht verstehen, wie Delegierte tatsächlich helfen können, wenn API ändert. Nun, natürlich, wenn es nur ein paar kleinere Änderungen sind, die Sie nur durch Ändern des Typs einiger übergebener Parameter oder nur eines bestimmten Feldes anstelle eines Parameters bewältigen können, dann kann es helfen, aber ich denke nicht, dass solche Situationen oft vorkommen, und Es ist nicht so schwierig und vielleicht sogar besser, den Methodenaufruf von einer verwalteten Bean oder was auch immer zu ändern. Während größere Änderungen erfordern, den Methodenaufruf trotzdem zu ändern.

Clients benötigen Caching Mechanismen für Business-Service- Informationen zu implementieren.

Caching ist eine schwierige Frage, ich weiß nicht, was und zwischenzuspeichern, wie es zu tun :) es bedeutet, dass ich einige Variable erstellen, die einige Ergebnisse gespeichert werden und ejb Anruf nur verwenden, wenn diese Variable zum ersten Mal aufgerufen? Ist es eine gute Praxis für solche gemeinsamen Ressourcen, wie es ein Delegierter sein sollte?

Es ist wünschenswert, Netzwerk Datenverkehr zwischen Client und Business Dienstleistungen zu reduzieren.

Wie können die Delegierten den Netzwerkverkehr reduzieren? Mit der gleichen Methode mit Variablen, die einige Werte speichert?