Pagina 2 di 2 primaprima 1 2
Visualizzazione dei risultati da 11 a 14 su 14
  1. #11
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,284
    Quote Originariamente inviata da cataDesign Visualizza il messaggio
    Praticamente spring non usa i java bean classici ma bensi un altro tipo di oggetto proprietario con un funzionamento simile ma migliore, dico bene?
    No, Spring tecnicamente è in grado di gestire qualunque tipo di oggetto, sebbene è ovvio che ha senso ed è tipico gestire oggetti che sono dei POJO (Plain Old Java Object) che a livello pratico vuol dire la stessa cosa dei Java Bean.
    A livello basilare un Java Bean=POJO è semplicemente e banalmente una classe che definisce oggetti che hanno "proprietà", accessibili usando una serie di convenzioni sui nomi dei metodi. Tutto qui. Poi le specifiche Java Bean effettivamente sono più complesse e contemplano ad esempio anche la gestione degli eventi. All'inizio infatti sono state pensate nell'ottica di definire "componenti" (specialmente quelli grafici GUI) che fossero riutilizzabili, "introspezionabili" e configurabili.
    Al giorno d'oggi quest'ultimo uso, cioè per componenti "grafici", non è più molto comune.

    Forse ti è utile anche: http://www.shaunabram.com/beans-vs-pojos/
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    java.util.function Interfaces Cheat SheetJava Versions Cheat Sheet

  2. #12
    Quote Originariamente inviata da andbin Visualizza il messaggio
    Poi le specifiche Java Bean effettivamente sono più complesse e contemplano ad esempio anche la gestione degli eventi.
    Con questa frase intenti queste specifiche?


    1. Have a public default (no argument) constructor
    2. allows access to properties using accessor (getter and setter) methods
    3. Implement java.io.Serializable


    onestamente ho letto l'articolo da te suggeritomi, che semplicemente dice che i POJOs sono dei Java Bean ma allo stesso tempo sono Spring Bean... cioe, come hai detto tu, sono delle normalissime classi che istanziano degli oggetti; ad esempio una classe Book istanzia un Bean "libroJava" che rappresenta un libro.

    La cosi tanto semplice affermazione (se corretta) mi porta a pensare che un POJO è un oggetto che non seguele le specifiche dei Bean (sopra scritte), mentre uno Spring Bean è un oggetto che rispettale specifiche dei Bean ma è gestito dal Framework e non dalla classe a cui ne affida i servizzi...

    Spero di non aver confusione nel mio cervello

  3. #13
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,284
    Quote Originariamente inviata da cataDesign Visualizza il messaggio
    Con questa frase intenti queste specifiche?

    1. Have a public default (no argument) constructor
    2. allows access to properties using accessor (getter and setter) methods
    3. Implement java.io.Serializable
    No, quelle che hai appena detto sono solo le caratteristiche più basilari/fondamentali dei Java Bean. Le specifiche Java Bean sono più complesse, le trovi a partire da qui:
    http://www.oracle.com/technetwork/ja...ec-136004.html

    Nella pagina di download, scarica il PDF di 114 pagine e te ne renderai conto ....

    Quote Originariamente inviata da cataDesign Visualizza il messaggio
    La cosi tanto semplice affermazione (se corretta) mi porta a pensare che un POJO è un oggetto che non seguele le specifiche dei Bean (sopra scritte), mentre uno Spring Bean è un oggetto che rispettale specifiche dei Bean ma è gestito dal Framework e non dalla classe a cui ne affida i servizzi...
    Dalla pagina: http://en.wikipedia.org/wiki/Plain_Old_Java_Object

    "The term "POJO" is mainly used to denote a Java object which does not follow any of the major Java object models, conventions, or frameworks."

    Questa in effetti è la spiegazione corretta del termine POJO, ovvero oggetti Java che non seguono un modello particolare, nemmeno convenzioni o framework particolari.

    I Java Beans invece seguono delle convenzioni, già anche solo per i nomi dei metodi "accessori". Ma anche qui non è sempre tutto nero o bianco. Non sei obbligato a seguire tutte le specifiche Java Bean. La tua classe banquet non l'hai marcata Serializabile. Non serve, ti funziona lo stesso. Ma a livello basilare segue almeno le convenzioni Java Bean per definire le "proprietà", perché questo è quello che richiede FreeMarker.

    Nel libro Spring in Action, Third Edition c'è un paragrafo che forse ti può illuminare:

    "Although Spring uses the words bean and JavaBean liberally when referring to application components, this doesn’t mean that a Spring component must follow the JavaBeans specification to the letter. A Spring component can be any type of POJO. In this book, I assume the loose definition of JavaBean, which is synonymous with POJO."

    Alla fin fine puoi chiamarli solo "bean" o "Java Bean" o POJO ... anche per me almeno al livello più basilare sono abbastanza equivalenti.

    In un file di configurazione dei bean di Spring puoi mettere:

    codice:
    <bean id="myBook" class="xyz.Book">
        <property name="title" value="Spring in Action"/>
    </bean>
    Questo è un comunissimo bean, Spring a runtime istanzierà Book e lo inserirà nel suo container dei bean. Ma vedi bene quel <property>, qui segue e deve seguire le convenzioni Java Bean, almeno a livello basilare, ovvero un metodo setTitle con un parametro compatibile con il value. Tutto qui.

    Quell'oggetto identificato da myBook lo puoi "iniettare" in un altro oggetto gestito da Spring. Ma alla fin fine cosa ci fa la applicazione con questi oggetti sono affari della applicazione ... non di Spring. Una volta che la applicazione riesce ad ottenere la istanza di quel Book, ci fa quello che vuole, anche invocare metodi particolari definiti in Book, es. dumo() o altro che non centrano nulla con i "Java Bean".
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    java.util.function Interfaces Cheat SheetJava Versions Cheat Sheet

  4. #14
    Grazie mille mi hai chiarito moltissimo le IDEE D thx molto. Darò un occhiata a quel PDF :P grazie ancora sei stato FANTASTICO!!!!!

Tag per questa discussione

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.