[Soci SLIP] Ancora NETBANS...

[Lucio Crusca]

In data mercoledì 12 gennaio 2011 09:11:30, roby.gir a libero.it ha scritto:
> Quindi, se ho capito bene, suggerisci di disegnare i controlli sulle
> classsi derivate, mentre la logica di business (movimento dati da/verso
> database, ed azioni di inserimento, modifica, cancellazione, stampa e
> ricerca con filtri) lasciarla alla classe base?

No. Suggerisco di togliere proprio la business logic dalle classi che hanno a 
che fare con l'interfaccia grafica e disegnarti tu una gerarchia di classi per 
la business logic. Di solito io procedo in questo modo:

Devo rappresentare il dato "clienti"

Creo sul db una tabella "CLIENTI"

Creo una classe Cliente (un java bean) con varie proprietà (ragione sociale, 
partita iva, etc...). Aggiungo metodi setXXX e getXXX per ogni proprietà  (lo 
fa Netbeans in automatico) e faccio in modo che sia possibile per altri 
oggetti mettersi in ascolto sui cambiamenti delle proprietà (in pratica faccio 
delle bound properties). Devo quindi avere una lista di listeners, ma questo 
lo fornisce già java (vedi PropertyChangeSupport).

Scrivo la classe di business logic (ClienteLogic o chiamala come vuoi) 
mettendola in ascolto sulle properties del javabean che mi interessano. Se 
voglio allo stesso modo realizzo il livello ORM per aggiornare il db a mano 
con i comandi SQL, oppure mi rivolgo ad un framework ORM di mio gusto e qui 
scrivo solo la business logic (ovvero, per esempio, quando cambio l'indirizzo 
email di un cliente esistente potrei desiderare che gli venga mandata un email 
automatica di verifica del nuovo indirizzo, è solo un esempio di cosa ricade 
nella business logic, non è detto che abbia senso fare proprio questo).

Fino a qui swing non esiste ancora. Ora lo aggiungo.

Creo una classe ClienteView (che NON deriva da JInternalFrame o altro, deriva 
da Object o da una generica classe View se devo scrivere metodi comuni a tutte 
le mie view). Questa classe contiene un JPanel (oppure se ho la classe base 
View il JPanel potrebbe essere là). Dentro il JPanel ci metto i campi del 
cliente (se voglio posso disegnare il JPanel col designer di NetBeans e poi 
usare un'istanza della classe risultante nella mia classe ClienteView). La 
view, se non uso il pattern MVC, sarà responsabile della validazione dei dati 
e dell'aggiornamento del javabean corrispondente. L'aggiornamento del database 
avverrà in automatico grazie alla parte ORM fatta prima.

Fino a qui gestisco un cliente per volta. Ora aggiungo la gestione dell'elenco 
clienti.

Creo una classe LIstaClienti che gestisce la lista dei clienti, crea nuovi 
clienti (javabeans) e contemporaneamente (o dopo la validazione) li inserisce 
nel database. Si occupa anche di cancellare dal database quelli che vengono 
cancellati dalla lista stessa. La classe ListaClienti dovrebbe anch'essa 
mettere a disposizione metodi per stare in ascolto sui cambiamenti apportati 
alla lista, in modo che la business logic (classe ListaClientiLogic) possa 
fare quello che deve nel momento in cui viene inserito un nuovo cliente o 
cancellato un altro (tipo mandargli il benvenuto oppure un questionario sul 
perché abbia richiesto la rimozione dei propri dati dal nostro database).

A questo punto inserisco la gestione grafica della lista clienti, quindi la mia 
ListaClientiView che NON deriva da JFrame o altri, ma contiene solo un JPanel 
che a sua volta contiene la JTable ed i tasti per le azioni sulla lista. 
Quando l'utente clicca su "Nuovo cliente", il metodo che gestisce questa 
azione crea un new Cliente(), lo inserisce nella lista, crea un 
JInternalFrame, crea una ClienteView, prende il JPanel della ClienteView e lo 
infila nel JInternalFrame di cui sopra. Procedura simile per il tasto Modifica.

Il metodo main della tua applicazione crea una ListaClienti, crea una 
ListaClientiLogic, una ListaClientiView, un JInternalFrame, prende il JPanel 
dalla ListaClientiView lo mette nel JInternalFrame e mostra il JInternalFrame. 
Ovviamente poi tutto questo andrà spostato in futuro dal metodo main() al 
metodo che risponderà alla voce di menù "Gestione clienti".

Discorso simile per articoli, fornitori, listini, preventivi, offerte, ordini, 
bolle, fatture, etc... 

Nota che in tutto questo, progettualmente distinguere i clienti dai fornitori 
sul database è un errore, in quanto essere cliente o fornitore non è una 
caratteristica propria, ma è uno stato che dipende da quale altra ditta si 
prende in considerazione e dall'istante in cui la si prende in considerazione 
(io oggi potrei essere tuo fornitore ma domani diventare anche tuo cliente... 
vuoi davvero reinserire tutta la mia anagrafica in entrambe le tabelle?). 
Quindi di solito si raggruppano tutti in una generica tabella "CONTATTI" e si 
aggiunge un campo che definisce lo stato di cliente ed un campo per lo stato di 
fornitore (oppure si calcola lo stato di cliente/fornitore di un certo 
contatto a partire dal fatto che esistano fattue attive/passive per quel 
contatto).

Spero di essermi spiegato... diversamente più di così via email diventa dura, 
al limite se c'è interesse in merito organizziamo un incontro per 
sviluppatori.