Newsgroup: it.comp.lang.delphi
Titolo: Sviluppare per .Net

Ho dei progetti Win32 (gestionali per piccole aziende 2-3 posti lavoro) che
usano comedb Firebird e Delphi Win32 , uno ancora in D4, altri in D2009.
Non ho esperienza , ma il grosso dubbio e' se abbia senso fare un gestionale
in .Net :
- Il piccolo artigiano che ha un Pc vecchiotto con WinXP e lo usa per
gestire  Magazzino/Fatturazione, in termini di  utilizzo pratico che 
benefici
avrebbe ?
credo che il tutto girerebbe piu' lentamente, appesantito dal Framework
- Sostituire la parte web ora appoggiata a Webservice di terze parti ?
A livello reporting uso QuickReport 4.5 , e credo anche questo andrebbe
cambiato,mentre per l'ambiente resterei su D2009.Net (al momento non
ho intenzione di migrare a D2010 o XE).
Come gia' detto .Net e' un grosso interrogativo, di cui non vedo la reale
utilita', se pero' ritenete che al contrario possa essere utile anche su
applicativi gestionali, magari postate qualche argomento, cosi' mi documento
Maurizio

 cosi' mi documento
per come la vedo io, l'unica vera utilità è per Microsoft, che in
questo modo riesce a vendere i suoi sistemi di sviluppo cercando di
chiudere i programmatori nel suo orticello in funzione di un futuro
sistema operativo tutto .net con blindature di sicurezza tali che
dovrai pagare o passare per Microsoft per qualunque cosa, un pò come fa
la Apple già oggi con i software per Ipad e Iphone.
Di vantaggi reali e concreti, per il resto, ce ne è soltanto uno: la
community del .NET, che è molto ampia e organizzata. Il resto è fuffa,
a meno che tu non debba affrontare la programmazione web integrandola
col mondo desktop. Valuta tu.
Ale

Concordo con quanto detto da Ale e aggiungo che una architettura 
framework come il .Net avrebbe dovuto quanto meno fornire un concreto 
supporto multipiattaforma ma così non è stato. Il .Net è nato per 
combattere Java, ma per tutte le applicazioni che hanno bisogno di 
sfruttare appieno caratteristiche della macchina e avere accesso a 
qualsiasi periferica, il Win32 sarà sempre la piattaforma di 
riferimento. A parer mio quindi Delphi Win 32 ora è sempre. Poi ci sono 
i vari casi da analizzare ma si fa lunga.
-- 
Il silenzio ti fa vedere ciò che il rumore non ti fa cogliere ..

 applicativi gestionali, magari postate qualche argomento, cosi' mi documento
Resta su win32 se ti occupi di gestionali: sono d'accordo con gli altri 
pareri espressi, .net sui gestionali di tipo *desktop application* non 
attecchisce.
Nota che se ci spostassimo lato web application , allora cambierebbe 
tutto, e di molto: delphi su questa piattaforma ("server side") non ha 
conquistato il mercato lasciando la scena a php, 
asp.net
, java.
Giusto per citarti un solo esempio: zucchetti usa delphi per il 
gestionale per le PMI mentre per il segmento ERP utilizza una struttura 
client server con linux/cobol come core. (e poi tutti pensano che il 
cobol debba scomparire..).
Restando in topic: ho trovato un solo gestionale italiano, opensource, 
scritto in .net: 
http://www.fborghi.it/geanet.htm
Dacci un'occhio e magari ne trai qualche ispirazione.
ciao
-- 
morde
D5,D6,D7
QT4.6.3 QT Creator 2.0

Maurizio ha scritto:





Mah, ti consiglierei di dare uno sguardo a .net, tutti i miei prossimi
progetti ne faranno uso.
-- 
http://www.kiva.org
Per il ng it.comp.lang.delphi: astenersi perditempo e lamer.
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

>
Direi che dipende da cosa faranno i tuoi progetti;
Per decidere di migrare a .Net si devono avere dei riscontri
concreti, e tra questi metterei la velocita' di esecuzuione su
Pc non recenti.
All'utente finale interessa solo che l'applicativo funzioni e non
gli faccia perdere tempo, poi che sia .Net o .Caz non gliene
frega niente. 

 frega niente.
Giusto, meglio che triboli lo sviluppatore :-))


 Giusto, meglio che triboli lo sviluppatore :-))
ahimč quanto hai ragione... :)
purtroppo questo č il nostro lavoro: a volte ti trovi a lottare per 
convincere artigiani avari che hanno in magazzino un 486 con il dos 6.2 
che devono decidersi a comprarsi un computer piů potente per sostenere i 
carichi dei software odierni.. :-O


 carichi dei software odierni.. :-O
per continuare a fare le stesse cose di quindici anni prima, delle
fatture, ddt e poco altro

 ha scritto nel messaggio
news:4c91abcf$0$40279$4faf...@reader2.news.tin.it...

La reale utilità di .NET  (ma anche di altre piattaforme) è nella creazione
di gestionali distribuiti tra più utenti e in sedi remote, connessi
ad un  web-server locale o remoto.
Se il tuo artigiano avesse la figlia che da casa stampa le fatture che
l'artigiano carica con una distinta di lavoro dal suo laboratorio,
allora .NET potrebbe aiutarti utilizzando internet come strato di
comunicazione e un server web + database
Il vantaggio sarebbe che a gestire il tutto è un server web
indipendentemente
dal PC utilizzato, dove TU da remoto puoi fare manutenzione al DB, e al SW
senza necessariamente andare dall'artigiano o eseguire sessioni remote,
ecc..
Pascal in tutto questo ce lo fanno entrare a forza con le nuove release di
Delphi. ma c'entra ben poco.
Tanto vale studiarsi e applicare le nuove tecnologie .NET
e ovviamente NUOVE LIBRERIE......
C.

 ad un  web-server locale o remoto.
tutto molto bello, peccato si scontri con una realtà ben diversa, vedi
questo articolo
http://www.ilsoftware.it/articoli.asp?id=6560
praticamente si stà spingendo gli utenti a comprare dei Tir per girare
in stradine strette dei centri cittadini e per trasportare alla fine
due o tre buste della spesa, quando alla fine potrebbe almeno per ora
fare tutto quanto e molto più economicamente con una piccola
utilitaria, non mi sembra una politica onesta verso il cliente finale

 utilita' [...]
Le cose non sono utili (o inutili) in senso assoluto: hanno la loro 
sfera d'impiego e le loro caratteristiche, e come tali vanno valutati in 
base alle esigenze.
Dovresti piuttosto dire qual è il tuo problema, o in cosa sei limitato, 
e in tal caso si possono suggerire le tecnologie, le librerie e i 
componenti in grado di darti una mano a risolverlo.
Ciao,
   Marco.
-- 
MARCO BREVEGLIERI
  (
http://www.marco.breveglieri.name
)

 Giusto, meglio che triboli lo sviluppatore :-))
Come se scrivere gestionali in .NET fosse un percorso privo di 
stranezze... :)


>
l'idea sarebbe di consentire l'accesso al db da remoto, sia per inserimenti
che consultazioni e stampe, e a quanto si legge .Net potrebbe agevolare
operando su un ambiente unico, certo si potrebbe sempre fare una
maschera in Java ed inviare i dati al db (Sql Server o Oracle).
Al momento non ho problemi specifici, e' una fase di sondaggio/valutazione,
infatti prima di decidere se passare a .Net bisogna anche capire quali
strumenti sono disponibili.
Certo e' che anche la parte economica va valutata, i costi delle varie
librerie per .Net oltre che per i Report.
Anche per il cliente non sarebbe "indlore" Oracle e SqlServer richiedono
la licenza d'uso, e trovare qualche provider che fornisca Firebird.Net
penso sia arduo.
Dalla parte opposta si trova VisualStudio con VisualBasic.Net che mi pare
abbia una versione di Crystalreport inclusa, e a livello frameword fino a
tempo fa Codegear era sempre indietro di una versione rispetto a Ms.
grazie
ciao Maurizio

 tempo fa Codegear era sempre indietro di una versione rispetto a Ms.
Delphi Prism (che è molto sinteticamente "Delphi integrato in Visual 
Studio") esce praticamente in contemporanea al rilascio delle nuove 
versioni di Visual Studio.
Ad ogni modo, come dicevo sopra, il problema qui non è del linguaggio, 
ma della scelta di campo tra VCL Win32 e .NET Framework che sono cose 
ben diverse ed è una migrazione che, secondo me, va fatta avendo solide 
e valide motivazioni. :)


 penso sia arduo.
Oracle, sqlserver, db2 offrono versioni "lite", le express, che sono 
gratuite anche per usi commerciali. A meno di non avere carichi enormi e 
necessità di scalare/distribuire pesantemente, quelli sono da considerarsi.
Riguardo firebird, leggiti questo link:
http://www.firebirdsql.org/dotnetfirebird/
io non l'ho provato ma potresti farlo tu, e farci sapere nelle tue 
valutazioni come ne esce questo provider.



e da un'altra, sempre sua, in un altro messaggio:
"Secondo me, hai invertito la direzione del ragionamento: verifica quali 
sono le richieste che ti vengono fatte sul tuo gestionale, e solo allora 
valuta se migrarlo a un'architettura .NET possa avere senso."
Io mi trovo guarda caso di fronte ad un problema specifico, di cui posso 
descrivere in modo preciso i confini. Spero che questo "caso" possa poi 
essere di spunto per riflessioni generali.
La necessit� � quella di riscrivere un'applicazione che pi� che 
gestionale direi che � di produzione.
Girer� su una LAN di un centinaio di terminali, di cui una quarantina 
collegati a vari tipi di "macchine", in definitiva interfacciandosi 
quasi sempre tramite porte seriali; in questi ultimi il lavoro � 
cadenzato (cio� le transazioni devono avvenire entro un certo tempo e ad 
intervalli regolari) ed � quindi vitale un'ottima gestione delle 
temporizzazioni.
Si occuper� di circa 600.000 transazioni al giorno, effettuate grosso 
modo sempre sulle stesse 5-6 "grosse" tabelle (da svariarte centinaia di 
migliaia a qualche milione di record) ed il totale delle funzionalit� da 
realizzare � piuttosto elevato, dato che l'applicazione attuale � frutto 
di circa 18 anni di codifica in CLIPPER e una decina d'anni di codifica 
in Delphi 5.
Non ci sono particolari necessit� di interfaccia (Ribbon, Gesture ed 
altre cose "sfiziose" risultano inutili), ma ovviament el'ergonomia � 
importante, e comunque c'� una parte di "lavoro di ufficio" da coprire; 
tale parte ha un basso impatto ma copre circa 250 form.
In alcuni casi alcune postazioni devono anche comunicare via TCP/IP 
invece che tramite il DB centrale per ottimizzare alcune prestazioni (ad 
esempio l'emissione di messaggi sonori in diverse parti dell'azienda, 
con ritardi di esecuzione minimi rispetto all'evento che segnalano).
Attualmente l'azienda possiede un ottimo Know-How di CLIPPER (ovviamente 
ormai inutile) e di Delphi 5, nonch� una buona base anche di D2009/2010, 
conoscenze che sono concentrate tutte in una sola persona, che 
ovviamente sono io, e che come consulente esterno ma a 360 gradi ha un 
costo che va considerato.
La richiesta che mi � stata fatta � di valutare l'opportunit� di 
utilizzare C#.NET oppure Java in alternativa a Delphi.
Ora, sicuramente nel caso specifico il vantaggio primo nell'uso di 
Delphi sta nel fatto che � una tecnologia consolidata in azienda: con 
l'occasione si passa dal D5 al D2010 e si usa dunque un approccio pi� 
moderno, ma i bagagli di conoscenze possono essere sfruttati quasi 
immediatamente.
Dovendo migrare a C# o Java la prima cosa sarebbe ovviamente la 
necessit� di impararli. Ammetto il mio completo digiuno su entrambi i 
fronti (uno non pu� conoscere tutti i linguaggi, come � stato detto in 
altro messaggio!), comunque sia, dato che, dopo 10 anni di 
frequentazione di quest'azienda, sono di fatto l'unico che ne conosce 
abbastanza bene il SW anche il core in CLIPPER l'ho scritto solo per il 
20%, � gi� stato sancito che il costo per insegnare ad un esperto C# o 
Java 10 anni di procedure aziendali � maggiore di quello per insegnare a 
me a migrare a C# o Java (C# sarebbe probabilmente pi� semplice data la 
similitudine di approccio).
Al di l� per� dell'opportunit� di essere pagato per imparare un nuovo 
linguaggio, che a me andrebbe pi� che bene, mi chiedo comunque se vi sia 
una "scelta migliore" tra le piattaforme citate, oppure se ve ne sono altre.
A me pare, appunto, che per realizzare applicazioni Client/Server su LAN 
per Win32, con la necessit� di interfacciare dispositivi con timing 
precisi in poco tempo e con facilit� di eseguire modifiche rapidamente e 
di metterle in produzione, Delphi 2010 non sia cos� facilmente battibile.
Ma non conoscendo gli altri sistemi se non "di nome" non ho strumenti 
per avvalorare la mia impressione, e non avendo mesi o anni di tempo, ma 
GIORNI o al massimo QUALCHE SETTIMANA per decidere (e non parlo di un 
periodo di tempo che posso dedicare interamente ai test, anzi!), proprio 
non so che pesci pigliare.
Un grosso grazie a chi avr� voglia di esplorare questo marasma.
-- 
byez
Piero

 non so che pesci pigliare.
Ciao Piero ormai qui ho scritto talmente tanto la mia opinione, che 
credo saprai cosa sto per risponderti :-D
La tipologia di software calza a pennello per delphi, e tu hai il 
know-how necessario per fare tutto, in delphi ci sono svariate librerie 
win32 per gestire le seriali e anche per il socket programming (torry, 
delphi300, async pro, ecc..).
Tuttavia, lasciami spendere qualche parola di motivazione e di sfida: 
considera quanto tempo hai per sviluppare il prototipo, e vedi se hai i 
margini per considerare .net (oppure QT perch� no? :-))
I plus per te sarebbero:
1- aggiornamento professionale
2- diventare competitivi in un mercato per te nuovo ma ricco di 
occasioni (quello dei programmatori .net C/C++)
3) utilizzare la conoscenza acquisita con .net per aprirsi delle porte 
verso altri ambienti quali quello server side (c# --> 
asp.net
)
Ovviamente, tutto questo vale se hai tempo per poter iniziare a formarti.
restare su delphi in questo caso ti garantisce:
1 - tranquillit� perch� ti muovi in un ambiente di programmazione che 
ben conosci
2 - risultati certi
3 - stime dei tempi attendibili
Alla fine, il mio consiglio � che se hai tempo per gestire il tuo 
learning, vale la pena imparare un nuovo linguaggio tra quelli 
conosciuti come "mainstream".
Saluti :)
-- 
morde
D5,D6,D7
QT 4.7.0 - MingW- QT Creator 2.1

 Piero
Io opterei per rimanere in Delphi ma userei la versione 7
molto pi� performante della 2010, senza unicode che a te non serve
e con i bache della 5 risolti
Auguri !!
C. 

 di metterle in produzione, Delphi 2010 non sia cos� facilmente battibile.
Io darei un'occhiata al nuovo *DataSnap* (se il tuo D2010 appartiene 
almeno alla versione "Enterprise"), oppure scaricherei una trial di 
*Delphi XE* e seguirei alcuni dei video formativi con le sessioni della 
"CodeRage 5" che sono stati pubblicati da poco e che descrivono come 
realizzare applicazioni con questa tecnologia.
Secondo me, per chi lavora in Delphi, � il passaggio pi� breve e offre 
delle funzionalit� interessanti.
Passando a .NET, credo che la soluzione pi� adatta all'architettura che 
hai presentato sia l'adozione di WCF, per� richiede formazione ed 
esperienza per essere sfruttata a fondo.
Ciao,
   Marco.


 e con i bache della 5 risolti
Non ï¿œ che Unicode sia l'unica differenza tra D7 e D2010... :D
E' un discorso un po' riduttivo, senza contare che - parlando di 
comunicazioni seriali - dubito che lo stesso Unicode possa rappresentare 
un "collo di bottiglia", fermo restando che dall'uscita di D7 anche le 
macchine su cui girano i programmi sono un po' cambiate. :)
Ciao,
   Marco.
