Newsgroup: it.comp.lang.delphi
Titolo: Package e distribuzione

Ho un'applicazione costituita da più eseguibili, ognuno dei quali comincia a 
diventare veramente pesante in termini di dimensioni, con conseguente 
problema di deploy degli aggiornamenti.
Sto seriamente pensando di suddividere il tutto in package di run time (non 
l'ho mai fatto), ho anche chiara la suddivisione, ma mi è sorto un dubbio: 
chiunque riceve questi package integrandoli in un progetto con un 
compilatore Delphi può accedere in maniera visibile all'interfaccia delle 
classi contenute, giusto?
Se fosse vero non sarebbe molto simpatico, visto che nel package finirebbe 
tutta la parte più fondamentale dell'applicazione, cioè la business logic.
Qualcun'altro si è posto questo problema?

scusa, Roberto.
Visto che devi cmq metterci le mani xche non ottimizzare il codice 
risolvendo il problema alla radice?
Usare i runtime pkg la vedo un po una pezza...
A.

Alberto Salvati  ha scritto:

Ti ringrazio per il consiglio e tra le altre cose sono in piena fase di 
refactoring (e quindi di ottimizzazione).
Ma a parte tutto, l'applicazione è "grossa" perchè è un gestionale con 
parecchie funzioni, suddiviso in moduli (eseguibili) comunque abbastanza 
grossi (circa 3 mb l'uno).
In effetti nella mia domanda precedente temo (per ignoranza) di aver fatto 
confusione tra package di design time e package di run time.
Io sono interessato a quest'ultimi, e leggendo un pò meglio la 
documentazione, mi sembra di capire che come per le dll se non si conosce il 
punto di accesso non sono utilizzabili da terzi (è quello che cerco), con la 
differenza rispetto alle dll che è possibile anche esportare classi e non 
solo funzioni.
Me lo confermate? 

 Me lo confermate?
Sì.
Tieni presente che i package compilati SONO delle DLL a tutti gli effetti.
La tua idea di suddividere l'applicazione in più moduli è corretta ed è
ciò che normalmente si fa, ad esempio, quando si vuol racchiudere
funzionalità comuni a più applicazioni nello stesso progetto.  Valuta
anche la possibilità di avere package che siano E di design-time, E di
run-time.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

"Roberto Casarini" ha scritto nel messaggio

Trovi in giro diverse informazioni a riguardo:
* Dynamically Load Components From Packages at Run-Time
By Bob Swart, Delphi Pro
http://www.inquiry.com/techtips/delphi_pro/10min/10min0301-1.asp
* BPL vs. DLL
http://delphi.about.com/od/objectpascalide/l/aa010901a.htm
* Dynamic World of Packages
http://delphi.about.com/od/objectpascalide/l/aa012301a.htm
* Dynamic packages in Delphi
http://dn.codegear.com/article/27178
* Un post interessante
http://snipurl.com/1aijx
Ciao
-- 
ACSH
[TurboDelphi]
Chi fa da se', fatica il doppio

Roberto Casarini ha scritto:

Scusa la domanda come hai risolto, o pensi di risolvere, l'accesso ai
dati dai package ?  Io ho lo stesso problema, devo iniziare a scrivere
un'applicazione in moduli, ma volevo avere una connessione aperta
all'avvio del exe principale e poi passare come parametro la connessione
ai vari package ma non so se sia la soluzione migliore.
Max

 Max
Bella domanda.
In verità non ho ancora affrontato il problema per cui non ho una risposta 
definitiva.
Pensandoci le soluzioni che mi vengono in mente (ma sono assolutamente 
incerte) sono queste:
1) La connessione viene contenuta in una classe di tipo Singleton, in modo 
che quando istanzi una connessione da qualsiasi punto del codice, in realta 
ti rifai sempre alla stessa connessione. Ma non so se funziona tra moduli 
diversi, e ho qualche dubbio.
2) Se le operazioni dei vari moduli sono sufficientemente "atomiche", si può 
tranquillamente pensare di avere una connessione per ogni modulo e passare 
soltanto i parametri di connessione (userid, pwd, ecc).
Finito l'uso di una det. funzione sul modulo, ci dovrebbe essere un 
meccanismo che chiuda la connessione del modulo stesso (non so se mi sono 
spiegato).
Nell'insieme non dovrebbe provocare tanto traffico sulla rete.
Approfitto di questo post per ringraziare ACSH per i link e Andrea Laforgia 
per la risposta. 

tranquillamente pensare di avere una connessione per ogni modulo
Assolutamente no. Per quale motivo ? per agevolarti la vita a
discapito del sistema ? E' un inutile spreco di risorse e in un
contesto critico, far proliferare le connessioni è pericolosissimo.

 contesto critico, far proliferare le connessioni è pericolosissimo.
In realtà io pensavo ad un sistema che apra e chiuda una connessione 
atomicamente, cioè ad ogni operazione (popolare un CDS, eseguire una query, 
ecc) però è solo teoria, non l'ho mai usato (uso anch'io la classica 
connessione da datamodule con il KeepConnection a True).
Non posso però fare a meno di chiedermi cosa sia meglio: un'unica 
connessione sempre aperta anche quando non è utilizzata oppure tante 
connessioni aperte atomicamente (e quindi chiuse quando l'utente non fa 
nulla) e che non verranno mai usate più di una per volta, perchè l'utente 
può solo fare un'operazione per volta (thread a parte)? 

connessioni aperte atomicamente
Dipende che cosa intendi per "meglio".
Dal mio punto di vista, è sicuramente meglio una sola connessione
aperta (anche i connection pooler le tengono SEMPRE aperte).  Aprire e
chiudere una connessione comporta allocazione di risorse e tempi che
potrebbero non essere rapidissimi.

 potrebbero non essere rapidissimi.
Scusami ma continuo a non capire.
Cosa passo al package ? Il puntatore al datamodule ? Il puntatore alla
connection ?
Mi potresti postare un esempio ?
Grazie

connection ?
Non passi nulla al package, il datamodule lo metti semplicemente nel
package.

 Trovi in giro diverse informazioni a riguardo:
Ottimo post :)
ciao
-- 
Morde

 package.
E se lo carico dinamicamente ? L'exe non conosce il contenuto del
package, in questo caso come faccio ?

Max ha scritto:


Crei un package che contiene solo il datamodule, e lo rendi
"required" per ogni package che lo utilizza (oltre ovviamente 
all'applicazione principale).
Per "comunicare" informazioni attraverso i package IMHO la via piu'
semplice e' quella di utilizzare messaggi di sistema personalizzati 
(postmessage et simila). Queste informazioni o vengono delegate ai 
moduli quando sono caricati dinamicamente, oppure crei un sistema di
gestione centralizzato che gestisce tutto questo "traffico" (apertura e
chiusura form, caricamento e scaricamento dati, connessione e sconnessione
ai DB dei vari controlli DBAware).
Ciao
ACSH


 (postmessage et simila). 
Che vuoi dire ?


 package, in questo caso come faccio ?
Una domanda: perché non sperimenti ?



I vari moduli di una applicazione devo comunicare fra di loro e con
l'applicazione host: passarsi o condividere dati, segnalare eventi ed
eventualmente reagire ad essi, ecc...
Esempio: dall'applicazione principale carico un package dinamicamente,
lancio la form contenuta in esso con il metodo show, la uso, la chiudo.
Come puo' l'applicazione host sapere che la form figlia e' stata chiusa
per eseguire determinate azioni (anche fosse solo scaricare il package
con UnLoadPackage)?
Altro esempio: l'applicazione principale ha caricato diversi package,
ciascuno dei quali si occupa della gestione di una parte di un "oggetto"
(non in senso informatico) piu' complesso. La modifica da parte dell'utente
- attraverso una form - di alcuni parametri gestiti da un particolare 
package,
influisce su tutte le altre parti dell' "oggetto" gestite dagli altri 
package.
Come avvertire quindi gli altri moduli che sono state apportate queste
modifiche e devono quindi fare un "refresh" dei propri dati (per esempio,
il preview di una determinata immagine)?
Altro esempio: quando carico un package, vorrei che i menu e le toolbar
dell'applicazione principale si modificassero per riflettere questo stato.
Da quel poco che conosco, per gestire simili situazioni, si puo' usare
un metodo complesso (le interfaccie tipiche degli oggetti COM), un metodo 
oneroso
in termini gestionali (un loader o manager che amministra i vari 
moduli/package
visuali e non) e un metodo semplice ma poco versatile (i messaggi di 
sistema).
Spero di essermi spiegato (ma non ne sono molto sicuro ...)


il preview di una determinata immagine)?
Vedi sopra.
<snip>

 Ho capito male quello che vuoi dire ?
No, hai capito bene. Stiamo dicendo le stesse cose, credo
(non ho detto pero' che i package necessitino di una gestione
"speciale": ho semplicemente suggerito un paio di metodi
per gestire tali "comunicazioni", che prescindono dai package).
Ciao
ACSH