6.1 Hvad er JavaBeans

Allerede i slutningen af ​​90'erne begyndte Java-sproget aktivt at blive brugt til store serverapplikationer, hvor antallet af klasser måles i titusinder og hundredtusinder. Det var da ideen om at standardisere udseendet af Java-objekter opstod.

Hele Java-sproget blev ikke rørt, for ikke at fratage det fleksibilitet. Nå, bagudkompatibilitet og alt det der. Derefter udviklede de en række kriterier for den nye generation af Java-objekter og kaldte sådanne objekter Java Beans. Java er opkaldt efter et populært kaffemærke, så Java Beans oversættes bogstaveligt til "kaffebønner".

De vigtigste kriterier var:

  • Adgang til klassens interne felter går gennem getProperty().
  • At skrive data til klassefelter går gennem setProperty(value).
  • Klassen skal have en offentlig parameterløs konstruktør .
  • Klassen skal kunne serialiseres.
  • Klassen skal have equals(), hashCode()og metoderne tilsidesat toString().
Java university

Denne tilgang gjorde ansøgningerne mindre sammenhængende. Altid klart:

  • hvordan man opretter et objekt - der er en offentlig standardkonstruktør;
  • hvordan man får/sætter ejendomsværdien;
  • hvordan man overfører/gemmer et objekt (vi bruger serialisering);
  • hvordan man sammenligner objekter (ved hjælp af equals() og hashCode());
  • hvordan man viser information om objektet i loggen (brug toString).

Nu er det faktisk industristandarden, men det var engang en ny trend. Det lader til, at alle allerede skriver sådan her, selvom hvis du husker HttpClient og dets Builders, kan du se, at den nye standard er svær for nogen.

Sådanne objekter er meget udbredt, hvor deres vigtigste semantiske belastning er datalagring. For eksempel i GUI'er, databaser og JSP-sider.

6.2 JSP'er og JavaBeans

En af grundene til JSP'en var, at den kunne outsources til frontend-udviklere. Og hvad? Du har en person, der forstår HTML, lad ham skrive JSP. Java-programmører skriver deres del, front-end-udviklere skriver deres - alt er fint.

Og alt var fint, indtil frontend-udviklerne skulle forstå den skrevne Java-kode indlejret i JSP'en. Eller, endnu værre, skriv selv en sådan kode.

Java-programmører var heller ikke tilfredse med dette. Nå, bed fortæl, hvilke layoutdesignere er backend-udviklere? Ja, de kan ikke skrive andet end scripts. Ja, og hele programmeringsparadigmet siger, at det er en dårlig form at blande forskellige sprog i én fil.

Så kom ideen op, som de siger, at give frontend-udviklere mulighed for at arbejde med Java-objekter, som med HTML-kode. Hver HTML-tag er også et objekt med sine egne felter, hvorfor ikke arbejde med Java-objekter på en lignende måde?

Ikke før sagt end gjort. Tilføjet specielle tags og så er vi i gang.

Objektoprettelse:

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

Denne kommando oprettede et objekt med typen objectog indsatte det sessionunder navnet Name.

Objekter kunne gemmes i en af ​​fire butikker: applikation (global), session, anmodning og side. Det var også muligt at indstille en egenskab for sådanne objekter:

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

Du kan få egenskaben af ​​sådanne objekter som dette:

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

Et eksempel på brug af tags:

<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>