Newsgroup: it.comp.lang.delphi
Titolo: [Semi-OT] A proposito di .Net e applicazioni NON web

Ciao a tutti.
A causa del forte carico di lavoro mi trovo un po indietro sia come
versione di delphi sia
per quanto riguarda lo sviluppo su .Net, a prescindere dal rad.
Da impressioni raccolte un po qui un po la mi sembra che per chi fa
web l'impatto di .net sia stato veramente notevole...
Ma mi chiedo...
Per cio che riguarda applicazioni non web, come gestionali etc,
qualcuno ha sviluppato qualcosa? Se si, rispetto alle applicazioni
win32 avete notato rallentamenti, avete avuto particolari problemi in
fase di sviluppo? i tempi di sviluppo sono gli stessi?
Ciao e grazie per ogni risposta!
Pax vobiscum
A.

 fase di sviluppo? i tempi di sviluppo sono gli stessi?
E' un po' generica come domanda, nel senso che non ci sono molti 
"paletti" definiti con precisione.
Per quanto riguarda la mia esperienza, l'uso di Windows Forms è stato 
traumatico: benché il CLR e la libreria base del .NET Framework si siano 
rivelati molto curati, la libreria in questione è disseminata di bug; 
non che la VCL ne sia esente, ma con la prima ne ho trovati anche di 
parecchio banali, che impediscono anche solo di utilizzare le 
funzionalità principali di un controllo visuale... mi è sembrato, in un 
certo senso, di tornare indietro di 10 anni. Questa è la mia impressione 
per quanto riguarda la versione basata su .NET 1.1, che non è tuttavia 
cambiata molto per .NET 2.0.
Presumo che il motivo sia dato dal fatto che Microsoft tende a puntare 
sulle tecnologie espressamente Web, quindi 
ASP.NET
 al principio, e WPF e 
Silverlight ora.
Sempre per la mia esperienza personale, la libreria VCL mi pare sempre 
più produttiva nell'ambito dello sviluppo di applicazioni Windows (per 
così dire) standard, grazie ad alcune peculiarità architetturali della 
libreria stessa, come componenti ed elementi specifici.
Come dicevo prima, chiaramente si dovrebbero avere più riferimenti a 
qualcosa di particolare, di specifico e definito per poter fare un 
raffronto che non sia banale come quello che ho fatto io, o comunque più 
tecnico che personale.
Ciao,
   Marco.
-- 
MARCO BREVEGLIERI
  (
http://www.marco.breveglieri.name
)

 "paletti" definiti con precisione.
Si, hai ragione.
Diciamo che ci sono 3 aspetti di cui mi piacerebbe discuetere...
Il primo è la Windows Forms, di cui gia in passato nn si era parlato
prp bene...
Il secondo riguarda ado.net...
La storia di lavorare in logica disconnessa è qualcosa che in delphi,
anche se non in modo cosi avanzato, conosciamo gia grazie a midas, ma
sarei curioso di sapere se a livello di performance le cose sono
peggiori rispetto, ad esempio, ad ado o a dbexpress.
Infine, gli aspetti legati ad applicazioni distribuite.
So che nelle ultime versioni del framework remoting è stato
"fagocitato" da un altra tecnologia di cui ora mi sfugge il nome...Mi
piacerebbe sapere qlc a livello di performance e STABILITA' rispetto
alle cose "vecchie" tipiche din win32 come com, e dcom.
Infine, la domanda brutale...
Gli utenti finali sono soddisfatti delle performance delle
applicazioni o "rimpiangono" win32?
Ciao e grazie! :-)
A.


.....passa a javaaaaaaaaaaaaaaaaaaaaaaaaa....dotnet e' una cagata
pazzesca.............

 applicazioni o "rimpiangono" win32?
Agli utenti finali, in generale, importa poco su come è realizzata
un'applicazione. L'importante è che funzioni. L'aspetto e il funzionamento
delle applicazioni .NET non si distinguono da quelli delle vecchie
applicazioni Win32, anche perché il codice che gira è comunque e sempre
codice nativo della piattaforma.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 applicazioni o "rimpiangono" win32?
Anche qui, dipende dalle applicazioni, da come sono state fatte, dai 
requisiti... in senso così generico, non so se è possibile dare una 
risposta seria. Ho usato applicazioni .NET recenti su cui non ho 
riscontrato grossi problemi dal punto di vista delle performance.
In generale, da quello che mi è capitato di vedere in giro, quando ci 
sono problemi di performance la causa è quasi sempre una scelta 
architetturale sbagliata, piuttosto che problemi con una specifica 
libreria o framework.


 libreria o framework.
straquoto. tnx.
A.

 codice nativo della piattaforma.
ok, andrea.
grazie.
A.



Se quello che vuoi è un opinione, io sono dell'idea che passare da VCL
Win32 a VCL .Net (o addirittura WinForm) non ne vale prorpio la pena.
Se come me lavori in Delphi da un po' di tempo la mole di
librerie/componenti che già usi con soddisfazione è elevata.
Inoltre c'è un aspetto nell'uso del framework che non si adatta alle mie
esigenze e che esisteva anche nella BDE.
Della BDE ho sempre odiato il fatto che i miei clienti dovevano avere
*almeno* la mia versione di DBE installata, vale a dire che se passavo ad
un nuovo compilatore dovevo necessariamente aggiornare anche i miei
clienti.
Da quello che so anche con il framework .Net accade la stessa cosa, se
compilo un applicazione in 2.0 poi su 1.1 non gira (vale invece il
contrario che se compilo in 1.1 poi gira anche in 2.0). 
E poi ho lavorato tanto per avere programmi piccoli e portabili che l'idea
di avere un runtime (il framework) da fornire comunque con l'applicazione
(se vuoi essere sicuro...) di svariati mega prorpio non mi va giù.
Io da un po' sto attento a quali librerie utilizzo, cerco di orientarmi
verso codice che sia portabile, compilabile cioè anche in .Net, tipo
dbExpress o appunto la VCL.
Non so se questo potrà avere più o meno senso in futuro.
Queste le mie personalissime opinioni.
Ciao

 Queste le mie personalissime opinioni.
Ti ringrazio, Maurizio.
Lunga vita e prosperita'
A.

 A.
Ciao

 presente i piccoli centri e la copertura ADSL italiana...)
quoto.
:-((    prp dalle mie parti c'è una zona di qlc km quadrato dove
l'adsl nn arriva...
ciao

 Non so se questo potrà avere più o meno senso in futuro.
Può avere senso anche adesso, poiché non è detto che un domani non ti 
capiti una richiesta per un'applicazione diversa dalla tipologia a cui 
lavori generalmente, e in quel caso hai sicuramente più libertà di 
movimento.


 
Il contesto della mia affermazione è quello che ha posto Alberto, vale
dire:
"Per cio che riguarda applicazioni non web, come gestionali etc,"
Un gestionale classico, presupponendo l'uso di Delphi, al momento non lo
svilupperei in .Net.
Concordo sugli esempi che hai fatto, anche se (dal mio punto di vista)
rappresentano più eccezioni che la norma.
Ciao

 sia Delphi.NET sia C# per lo sviluppo
Sto iniziando a giocare con C# (Visual Studio 2008 Express). Non e' che
conosci qualche testo valido, anche in inglese, sul quale imparare?
Grazie
ACSH


 ACSH
Qualsiasi consiglio è subordinato all'uso di Turbo C#
http://www.turboexplorer.com/csharp
Sto scherzando, io non mi sono trovato male con il manuale sul .Net
generico della mondadori, alla fine tutto il codice di esempio è in C# per
cui....
Ciao

 rappresentano piů eccezioni che la norma.
Non penso sia una questione di punto di vista, ma di metodo d'impiego o 
comunque in base alla tipologia di software che si sviluppa: ciň che č 
un'eccezione per qualcuno, per altri puň essere tranquillamente la 
norma. :-)


 conosci qualche testo valido, anche in inglese, sul quale imparare?
Non ho ancora avuto occasione di leggere un manuale specifico su C# in 
quanto linguaggio.
Ho letto "CLR via C#" di Jeffrey Richter, che si concentra maggiormente 
sulla piattaforma .NET in quanto tale, usando C# come strumento per 
dimostrare e verificare quanto è scritto nel libro.
Secondo me, è un ottimo testo perché approfondisce ciò che più mi 
interessa, cioè le peculiarità della piattaforma, piuttosto che un 
linguaggio specifico, poiché mi interessa rimanere slegato da 
quest'ultimo, visto che ne uno più di uno a seconda delle occasioni.


 
http://www.turboexplorer.com/csharp
Turbo C# presumo andrà a morire in quanto le soluzioni basate su C# 
nell'attuale "CodeGear RAD Studio" sono state ridotte alla sola 
compilazione di file sorgenti, senza supporto designtime.
Per lavorare con C#, si usa Visual Studio.


 norma. :-)
Personalmente parlando, spero che diventi la norma anche per me: l'uso di
uno specifico linguaggio in funzione dell'architettura del progetto è da
vedersi come un PLUS.
-- 
Morde

 norma. :-)
Questa parte non l'ho capita, mi sembra che il senso sia quello che avevo
già espresso io.
Per me gli esempi che hai fatto non sono la norma, ma come ho già detto
vale per me, magari altri non fanno che sviluppare applicazioni che devono
fare i conti con altri SW, oltre al sistema operativo ovviamente.
Ciao
PS: non sapevo che C# andasse a sparire, è già così da RAD 2007?

 PS: non sapevo che C# andasse a sparire, è già così da RAD 2007?
Sì, ma per quanto mi riguarda è meglio, così si possono dedicare 
maggiori risorse a Delphi e alla libreria VCL. :-)


 quest'ultimo, visto che ne uno più di uno a seconda delle occasioni.
Grazie a te e a Maurizio per le risposte (Turbo C# non è una opzione
valida, purtroppo).
Ho cercato qualche notizia di "CLR via C#" con "Live Search"
- Google non mi funziona piu' - e sembra il libro che fa per me.
Al prossimo giro in libreria proverò a darci una occhiata (se si trova)
Grazie ancora.
Ciao
ACSH
-- 
Il più grande sbaglio nel progettare software
a prova di stupido è sottostimare l'enorme
ingegnosità degli stupidi.

 Al prossimo giro in libreria proverò a darci una occhiata (se si trova)
Dovresti poterlo trovare abbastanza tranquillamente anche su Amazon e 
affini, mal che vada. :-)


 affini, mal che vada. :-)
Si', lo so, ma li' non c'e' la cassiera che mi lancia sempre sguardi
languidi.
Ciao


 languidi.
rotfl!
A.