Beans vs. managed Beans vs. backing Beans Erklärung

[Dagobert]

Guten Tag,
Wie der Name schon sagt, ich bräuchte ne knackige Definitions von den 3 Beans.
Also was ne bean ist weiß ich, jedoch wird mir nicht der unterscheid zur managed Bean klar. Und mit ner backing bean kann ich iwie gar nix anfangen oO.
Mein Prof hat das nur sehr beiläufig erwähnt, und das muss bei mir untergegangen sein.
Es wäre nett wenn mich kurz wer theoretisch aufklären kann. (also kein code o.a.)

mfg. Dagobert

 

[nocturne]

Also eine Backing-Bean ist ein oberbegriff, eine spezielle variante davon ist die Managed-Bean.

Eine Managed-Bean ist meist langlebig im Session-Scope und bildet mit den Service-Beans die Controller-Ebene.

Eine Backing-Bean ist meist kurzlebig im Request-Scope und verbindet die Controller-Ebene mit der View-Ebene, ist aber meist nicht teil der Controller-Ebene.

 

[Sym]

Kannst Du dafür eine Quelle nennen oder ist das nur Dein Gefühl?

Laut Spec kann eine Managed-Bean alle Scopes annehmen, die es gibt. Und ich sehe eine Backing-Bean (in JSF) als Synonym dafür.

 

[Deadalus]

Das Problem ist einfach, das diese Begriffe doppelt und dreifach belegt wurden. Ihr habt also leider beide recht.

Eine Klasse braucht folgende Eigenschaften um eine Bean zu sein:

Öffentlicher Standardkonstruktor (Default constructor)
Serialisierbarkeit (Serializable)
Öffentliche Zugriffsmethoden (Public Getters/Setters)

Bei der Managed Bean wirds schon witziger. Da kann man jetzt Sagen eine Managed Bean ist eine Bean, die mit der JSF Annotation @ManagedBean annotiert wurde. Der kann man tatsächlich jeden Scope geben.
Allerdings kann man eine ManagedBean auch einfach als Bean verstehen, deren Lebenszyklus von einem Container gemanaget wird. (Also auch neue EJB's, CDI Klassen ...). Zu JSF 1.2 Zeiten hat man die Begriffe so verwendet wie sie nocturne beschrieben hat.

Fazit: Das ist Auslegungssache. Ich persönlich würde empfehlen eine Managed Bean als Oberbegriff für eine von einem Container verwaltete Klasse zu verstehen und den Begriff der Backing Bean einfach zu vergessen.

 

[maki]

Eine Klasse braucht folgende Eigenschaften um eine Bean zu sein:

Da beschreibst du eine JavaBean 😉

AFAIK sind BackingBeans auch nur ManageBeans, die von einem Tool (GUI Designer) erstellt wurden.

Ich persönlich würde empfehlen eine Managed Bean als Oberbegriff für eine von einem Container verwaltete Klasse zu verstehen und den Begriff der Backing Bean einfach zu vergessen.

Sehe ich auch so.

 

[JanHH]

managed bean ist ein technischer, klar definierter Begriff; backing-bean unspezifisch und "umgangssprachlich".

Abgesehen davon sind managed beans halt für sich betrachtete "vom container verwaltete beans", während backing beans logischerweise nur dann solche sein können, wenn sie etwas backen (also konkret, JSF-Seiten).

Ansonsten ist es auch ein Frage der Architektur der Anwendung. Eine Möglichkeit, JSF-Anwendungen zu bauen, ist es, pro JSF-Seite eine bean (die backing bean für diese Seite) zu haben. Das ist eher der Stil bei "alten" JSF-Anwendungen (ohne DI-Framework). Die Action-Beans (das, wo die eigentliche "Arbeit" der Anwendung implementiert ist, auch Anwendungslogig oder business-Logik genannt) sind stukturell da eher auf die JSF-Seiten hin fixiert. Eine andere Variante ist es, die Action Beans eher auf die Datenbank-Entities zuzuschneiden. Mit DI-Frameworks (Seam, CDI) hat sich das als "neuer" Stil durchgesetzt (weil man jetzt direkt EJBs in den JSF-Seiten ansprechen kann, was vorher nicht so ohne weiteres ging). So grob gesagt 😉.

 

[nocturne]

Kannst Du dafür eine Quelle nennen oder ist das nur Dein Gefühl?

1. Laut Spec kann eine Managed-Bean alle Scopes annehmen, die es gibt.
2. Und ich sehe eine Backing-Bean (in JSF) als Synonym dafür.

Zu 1: Ok, wenn ich schreibe "ist meist langlebig im Session-Scope" meine ich "ist meist langlebig und meist im Session-Scope" 😀
Zu 2: Da es z.B. in Struts die Action-Beans als Backing-Beans eingesetzt werden die sich klar vonManaged Beans unterscheiden würde ich mal sagen das Synonym nicht das richtige Wort ist, ich finde Oberbegriff oder Kategorie hier passender.