MVC : ma cosa sono i business object?

[matthew80]

Ciao a tutti,

ho alcune difficoltà ad afferrare alcuni concetti dell'MVC, forse perché il libro è un po troppo teorico per i miei gusti.
In particolare cosa si intende con il termine business object?

Spiegherò quel che ho capito a parole mie molto schematicamente e spero qualcuno voglia correggermi in caso di errori.

Per realizzare un applicazione web è bene che io la divida in tre livelli:

• Model, l'inserimento/estrapolazione di dati in un DB (JavaBean)
• View, la visualizzazione dei dati (pagine HTML e JSP)
• Controller, il processamento di questi dati (Servlet)

Se ad esempio voglio fare un'applicazione web che consente di inserire dei dati ad un utente attraverso una pagina HTML, salvare tali dati su un DataBase e visualizzare una pagina che confermi l'inserimento effettuato ed i dati memorizzati, allora creerò i seguenti file:

1) Form.html (View)
Creo una pagina HTML che contiene un form in cui l'utente può inserire nome, cognome ed età. Appena preme "Invio" questi valori vengono passati ad una servlet

2) UserServlet.java (Controller)
La servlet prende questi dati che Form.html gli ha passato e, attraverso le chiamate ai metodi della parte di Model che interagisce col database, li processa ed invia i risultati ad una JSP

3) User.java, UserIO.java (Model)
User.java è un javabean, ovvero, un oggetto che è la versione speculare della mia tabella, e UserIO.java ha le istruzioni JDBC utili ad interagire col DB.

4) Result.jsp (View)
E' una JSP che mostra i risultati che il Controller, cioè la Servlet, gli ha passato.

Se quello che ho scritto è giusto alcune domande mi sorgono...

• Quando si dice che "il Model rappresenta lo strato di business dell'applicazione" significa che il temine strato Model e strato business sono sinonimi, cioè ci si sta riferendo alla stessa cosa?
• Siccome il model "contiene i dati e fornisce i metodi per accedervi", allora a far parte del Model, nella mia ipotetica applicazione Web, è - oltre a User.java e UserIO.java - anche la tabella User del mio DabaBase, visto che è questa tabella che effettivamente "contiene i dati", mentre le classi di prima "forniscono i metodi per accedervi"?
• Per logica di business (o logica applicativa) cosa si intende di preciso?
• I business Object sono le classi, e quindi gli oggetti, dello strato Model...in altre parole le classi User.java e UserIO.java?

Insomma non ho capito un tubo del temine business...forse perchè lo traduco in "azienda" e non capisco che c'entra l'azienda in tutto ciò

Spero di essere stato chiaro e mi scuso per la prolissità.
Grazie dell'attenzione,

Matteo.

[Romeo25]

i BO sono oggetti java che contegono la logica del applicativo.

Per esempio tu hai un JavaBean come la classe User.java che ha solo lo stato del oggetto tipo avrà gli attributi di classe username e password con i suoi metodi get e set non avrà altri mettodi
invece nel utentiBO.java avrai gli stessi attributti della tuo bean ma avrai anche la logica del applicativo tipo un metodo login(). Dissolito nei BO viene applicata la logica per fare eseguire all'applicativo le richieste del cliente. Poi per il model ti dovresti vedere il pattern dao che spiega bene interagire dei BO con Model.

Spero di averti chiarito un po le idee.

[matthew80]

Anzitutto grazie della risposta.

Quindi - e correggimi se sbaglio - possiamo dire che i Business Object sono degli oggetti che contengono il codice applicativo delle mie web application, in altre parole il codice che esegue le funzioni chiave della mia applicazione, nel mio caso il login.

Siccome il termine business si traduce anche col termine italiano "lavoro" potrei dire che i business object sono "oggetti (=object) che fanno il lavoro (=business) principale della mia applicazione web"?
Siccome la mia applicazione riguarda il login allora il business object della mia applicazione sarà quella classe che implementa il codice effettivo di login, mentre le altre classi che compongono la mia web application sono "da complemento", servono cioè a far funzionare questo codice di login.

Secondo questo discorso il business object della mia applicazione di esempio dovrebbe essere UserIO.java?

Da quel che ho capito, quindi, i business object, siccome spesso lavorano con i DataBase, e quindi interagiscono con i JavaBean, fanno uso di questi JavaBean.
Ma se io creassi un JavaBean con all'interno anche il metodo per il login, oltre ai metodi set/get, sarebbe la stessa cosa...cioè questo JavaBean funzionerebbe anche da business object?
Diciamo che dividere i JavaBean e i business object è "solo" una questione di ottimizzazione?

I business object fanno SEMPRE parte del Model Layer, quello che interagisce con il DataBase? (A proposito...ma anche la tabella di MySQL fa parte del Model Pattern, siccome è lei che contiene i dati?)

Ultima domanda...dove posso trovare un buon tutorial sul pattern DAO? Ho trovato solo cose con i EJB e a me tale tecnologia non interessa.

Grazie dell'attenzione,
Matteo

[Romeo25]

Si possiamo dire che i BO(Bussines Object) contegono il codice applicativa anche se i BO sono dei oggetti reali quelli riconoscuti dal cliente per esempio il cliente ti dice che l'applicativo deve avere dei utenti che devono poter logarisi nel sistema e fare varie operazioni. per cliente l'utente e una persona che ha dei dati personali indirizzo telefono e altre informazioni percio l'utente sara il nostro BO ma il model sara diverso perche l'utente sara un insieme di oggetti mappatti in diverse tabelle come persona(con i dati personali) indirizzo(che puo averne diversi) percio il nostro BO Utente sara l'insieme delle classi del model Persona e Indirizzo.

Poi i javabean hanno solo il get e i set sono dei oggetti che non hanno dei comportamenti se ci metti della logica dentro non sarebbero piu dei oggetti contenitori di dati mappati con le tabelle ma oggetti che influenzano il comportamento del applicativo.

BO non fanno parte del model layer sono un layer a parte.

per quanto riguarda il dao poi vedere anche quelli con l'ejb considerando l'ejb come il tuo BO.

[Santino83_02]

Se vuoi puoi implementare non BO, ma scomporre la loro logica in due parti: javabeans + facade, dove facade sono classi (in genere una per ogni javabeans del model) che implementano la logica business (esempio, login(), AddNewUser(), etc)

[matthew80]

Quindi in pratica se ho queste classi per un applicazione di login é giusto scomporle in questo modo?

************************************************** *************************

[Premessa]

Il DB MySQL è una semplice tabella Utente con tre campi, ID, nome_utente e password

1) Form.html (View)

Creo una pagina HTML che contiene un form in cui l'utente può inserire nome utente ed password. Appena preme "Invio" questi valori vengono passati ad una servlet

2) UserServlet.java (Controller)

La servlet prende questi dati che Form.html gli ha passato e, attraverso le chiamate ai metodi della parte di Model che interagisce col database, li processa ed invia i risultati ad una JSP

3) User.java, Login.java (Model)

User.java è un javabean, ovvero, un oggetto che è la versione speculare della mia tabella (proprietà e metodi get/set)

Login.java ha le istruzioni JDBC utili ad interagire col DB, cioè il metodo per effettuare il login. Si serve di oggetti di tipo User. E' questo il mio business object

4) Result.jsp (View)
E' una JSP che mostra i risultati che il Controller, cioè la Servlet, gli ha passato.


************************************************** *************************

Il classico modello MVC prevede tre layer, ma prima mi avete detto che Il Business Object è un layer a parte....ho alcuni dubbi in proposito.
Non dovrebbe invece far parte del layer Model, visto che il layer Model è definito come "quel codice che contiene i dati o i metodi per interagire con essi"? Penso sia questa la cosa che non mi è chiara!

Cioè...da quello che ho capito alla fine il business object è una semplice classe ma gli viene dato questo nome giusto per far capire che è la classe che contiene il mio codice applicativo, cioè il metodo chiave e più importante della mia applicazione...allo stesso modo in cui anche un JavaBean non è altro che una semplice classe ma gli viene dato questo nome giusto per indicare che è quella classe che contiene la versione speculare ad oggetti della mia tabella.

Mi viene l'impressione che questi termini siano nati con l'intenzione di aiutare i programmatori a "dialogare" tra loro, nel senso che si fa prima a dire a qualcuno "fammi il JavaBean della tabella", rispetto a dire "fammi la versione speculare ad oggetti della tabella creandomi una classe che abbia come variabili i nomi delle colonne della tabella con dei metodi di lettura/modifica associati".

E' corretto quello che ho detto o sto facendo un sacco di confusione?

Grazie

Matteo

[Romeo25]

il tuo login sarebbe il tuo dao o la classe che fa le fuzioni jdbc questo oggetto ha gia delle responsabilita cioè quello di dialogare con il database percio non sarebbe molto pulita dargli delle altre responsabilita come gestire se la password e utente sono giuste responsabilta che dovrebbero appartenere ad un altro oggetto cioe il BO . percio il login.java riempira di dati il tuo bean e lo passera al BO che controllera se è uguale con quello inserito dal utente nel form in base al risultato ritornera un valore al controller (true o false ) e il controller in base al ritorno visulizzera o l'errore o successo del login. Tutto questo divisone e utile perche cosi faccedo dai a ogni oggetto una responsabilita. Metti caso che il cliente di dicesse di cambiare il database l'unica classe che dovressti andare a toccare sarebbe il tuo dao la calsse login.java che si occupa di dialogare con il database senza toccare gli arltri oggetti.