CodeGym /Java Course /Modulo 3 /Lavorare con JavaBean

Lavorare con JavaBean

Modulo 3
Livello 13 , Lezione 5
Disponibile

6.1 Cosa sono i JavaBean

Già alla fine degli anni '90, il linguaggio Java iniziò ad essere utilizzato attivamente per applicazioni server di grandi dimensioni, dove il numero di classi è misurato in decine e centinaia di migliaia. È stato allora che è nata l'idea di standardizzare l'aspetto degli oggetti Java.

L'intero linguaggio Java non è stato toccato, per non privarlo di flessibilità. Bene, retrocompatibilità e tutto il resto. Quindi hanno sviluppato una serie di criteri per oggetti Java di nuova generazione e hanno chiamato tali oggetti Java Beans. Java prende il nome da una famosa marca di caffè, quindi Java Beans si traduce letteralmente in "chicchi di caffè".

I criteri più importanti erano:

  • L'accesso ai campi interni della classe avviene tramite il getProperty().
  • La scrittura dei dati nei campi di classe passa attraverso il formato setProperty(value).
  • La classe deve avere un costruttore pubblico senza parametri .
  • La classe deve essere serializzabile.
  • La classe deve avere i metodi equals(), hashCode()e sovrascritti toString().

Questo approccio ha reso le applicazioni meno coerenti. Sempre chiaro:

  • come creare un oggetto - esiste un costruttore predefinito pubblico;
  • come ottenere/impostare il valore della proprietà;
  • come trasferire/salvare un oggetto (usiamo la serializzazione);
  • come confrontare oggetti (usando equals() e hashCode());
  • come visualizzare le informazioni sull'oggetto nel registro (utilizzare toString).

Ora è in realtà lo standard del settore, ma una volta era una nuova tendenza. Sembra che tutti scrivano già così, anche se se ricordi HttpClient e i suoi Builder, puoi vedere che il nuovo standard è difficile per qualcuno.

Tali oggetti sono ampiamente utilizzati dove il loro principale carico semantico è l'archiviazione dei dati. Ad esempio, nelle GUI, nei database e nelle pagine JSP.

6.2 JSP e JavaBean

Uno dei motivi per JSP era che poteva essere esternalizzato a sviluppatori front-end. E cosa? Hai una persona che capisce l'HTML, lascia che scriva JSP. I programmatori Java scrivono la loro parte, gli sviluppatori front-end scrivono la loro: va tutto bene.

E tutto è andato bene finché gli sviluppatori front-end non hanno dovuto comprendere il codice Java scritto incorporato nel JSP. O, peggio ancora, scrivi tu stesso tale codice.

Anche i programmatori Java non erano contenti di questo. Bene, per favore dimmi, quali progettisti di layout sono sviluppatori di back-end? Sì, non possono scrivere altro che script. Sì, e l'intero paradigma di programmazione afferma che mescolare lingue diverse in un file è una cattiva forma.

Poi è nata l'idea che dicono di dare agli sviluppatori front-end l'opportunità di lavorare con oggetti Java, come con il codice HTML. Ogni tag HTML è anche un oggetto con i propri campi, perché non lavorare con gli oggetti Java in modo simile?

Detto fatto. Aggiunti tag speciali e via.

Creazione oggetto:

<jsp:useBean id="Name" class="Object type" scope="session"/>

Questo comando ha creato un oggetto con il tipo objecte lo ha inserito sessioncon il nome Name.

Gli oggetti possono essere archiviati in uno dei quattro archivi: applicazione (globale), sessione, richiesta e pagina. Era anche possibile impostare una proprietà di tali oggetti:

<jsp:setProperty name="Name" property="propName" value="string constant"/>

Potresti ottenere la proprietà di tali oggetti come questo:

<jsp:getProperty name="Name" property="propName"/>

Un esempio di utilizzo dei tag:

<body>
    <center>
        <h2>Using JavaBeans in JSP</h2>
        <jsp:useBean id = "test" class = "com.example.TestBean" />
        <jsp:setProperty name = "test" property = "message" value = "Hello JSP..." />
        <p> What-to do important</p>
        <jsp:getProperty name = "test" property = "message" />
    </center>
   </body>
Commenti
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION