Quale linguaggio Web?

[shinya]

Originariamente inviato da Galileo

grasse risate, grasse risate
Io sono ancora in attesa della definizione di applicazione enterprise seria e del perché solo JavaEE va utilizzato.

Te lo spiego io cos'è "un'applicazione enterprise seria".
Per capirlo, bisogna sapere che il 99% dei responsabili IT di quelle poche grosse aziende italiane che abbiamo sono uomini/donne con un'età superiore ai 50 anni, che hanno scritto il loro ultimo programma in COBOL 25 anni fa.

Questo quando va bene.
Quando va male, quel programma non l'hanno nemmeno mai scritto e sono capitati in quella posizione per amicizie/coincidenze/casualità o, ancora peggio, raccomandazioni all'italiana (che non sono le stesse raccomandazioni che avvengono all'estero).

Detto questo, bisogna anche sapere che queste sono le stesse persone che hanno l'ultima parola nella scelta delle tecnologie da utilizzare. Gli sviluppatori, NON scelgono le tecnologie con cui lavorare, nelle grandi aziende.

Succede quindi, il contrario di quello che sarebbe normale succedesse.

Bisogna poi sapere che i vecchi responsabili IT sono persone che non si aggiornano, non leggono almeno 1 libro tecnico al mese come consigliano quelli di The Pragmatic Programmer, non leggono reddit, non leggono i paper su da Lambda the Ultimate, e ovviamente, non programmano.

Le loro uniche fonti di informazione sono volantini pubblicitari di altre grandi aziende (Oracle, Sun, Microsoft, ecc...) che arrivano in ufficio, parlando di SOA e altre stronzate. Poi ci sono i commerciali delle aziende (o altre aziende partner) di cui sopra, che ogni tanto arrivano cercando di vendere qualche nuovo prodotto o funzionalità.

E' forte l'illusione che spinge a credere che legarsi ai prodotti di una grande azienda sia fonte di sicurezza, di stabilità, o peggio ancora, di supporto nel futuro. Dopotutto J2EE risponde a delle specifiche no? Quindi se ci atteniamo a quelle specifiche andrà tutto bene...

Questo è il motivo per cui nelle grandi aziende si usa Oracle, Websphere, ecc... E' più serio capisci? Sono venute qui delle PERSONE a parlarmene! In giacca e cravatta eh! Chi viene a parlarmi di Django? Nessuno, nella migliore delle ipotesi. Nella peggiore, può saltar fuori un consulente esterno in jeans che ti accenna velatamente (perchè i responsabili IT non solo non sanno di essere ignoranti, ma sono pure permalosi) ad altri modi di fare le stesse cose.

Ovviamente non devo star qua a confutare questo modo di ragionare, sappiamo tutti che sono stronzate.

Questo è il concetto di "serietà" all'interno della "enterprise".
Potrei andare avanti per ore e scriverci un libro forse.

Sorvolo sul discorso del chi ce l'ha più lungo tra J2EE e Django e salcazzo cos'altro. Personalmente non mi piacciono gli ORM come concetto. SQL non è il problema, dal mio punto di vista.
Mi piace abbastanza J2EE fino a quando rimane a JSP/JSTL/Servlet. Quando si arriva a parlare di persistenza, di JPA, di EJB e compagnia, mi sembra di vedere la seconda stagione di Twin Peaks.
Poi la cosa che mi fa incazzare di questi framework è che tutta la documentazione che c'è in giro, parlo di Java perchè è ciò che uso quotidianamente, è il solito tutorial del tipo "Ecco, vedete com'è facile fare 'select * from table'? Questo esempio funziona benissimo con Apache Derby!".

Nell'enterprise NON esiste 'select * from table' e NON esiste Apache Derby!
Le informazioni sono sparse su db un pò qui e un pò là, su connessioni diverse, in posti diversi. E c'è Oracle. O Sql Server. O al massimo DB2. Basta.

Qualcuno mi fa vedere il codice per richiamare una stored procedure pl/sql su Oracle via JPA? Tipo una semplice procedura che mi ritorni un ref cursor con i risultati di una select (l'esempio non è campato per aria).

Ma vabbè mi fermo qua perchè poi si va sul gusto personale e non mi sembra il caso di aprire discussioni... anche se avrei qualche dubbio anche sull'approccio MVC su web...

[Galileo]

Originariamente inviato da dupa

La cosa simpatica è che si è partiti dalla tua affermazione secondo cui Silverlight fosse qualcosa di enterprise, io ho detto che Silverlight è qualcosa di paragonabile a Flex, e ora stai tirando in ballo il framework .NET che non c'entra nulla.
Parliamo di tecnologie per presentare i dati, .NET non c'entra nulal in questa faccenda.

Il tutto è partito dalla tua affermazione ridicola, che sa molto di project manager fallito che va in giro bello agghindato e poi non scrive mezza riga di codice, quando hai scritto che per fare applicazioni web serie si usa J2EE senza mezza argomentazione.
Primo.
Secondo, che non c'entri nulla è una ovvia stupidaggine (ancora?), perché 1) il framework NET mi è indispensabile per costruire un'applicazione web Silverlight, 2) il confronto l'ho fatto con J2EE e quindi lo si fa a tutto tondo; io mi sono permesso a ragion veduta di dire che J2EE è indietro con lo sviluppo e Silverlight ne è una riprova (ma ce ne sono altre, tra cui LinQ e tutte le novità apportate dal framework stesso 3.0 e 3.5).

Ai miei punti di fatto non hai risposto, ne deduco che tu non ne sia in grado.
D'altra parte tranne snocciolare un paio di numeri (sì poi su un ORM, avessi detto chissà cosa) e un quote parziale di un thread in cui per altro venivano spiegate le differenze tra Silverlight e il resto della ciurma, non hai fatto, per cui...

qualcuno ti ha mai spiegato che la Microsoft stringe accordi commerciali per diffondere la sua tecnologia Silverlight e per costringere le persone a installare il suo plugin?
secondo te perchè Ryanair (sito con milioni di accessi) ha messo la mappa delle destinazioni in silverlight, quando la vecchia versione flash (accessibile da oltre il 90% dei browser) faceva il suo dovere?

Perché Adobe invece cosa fa, regala noccioline o fa beneficienza invece di stringere accordi con i partner commerciali? Ti rendi conto che ti stai rendendo ridicolo?
Ryanair ha fatto un mero calcolo di convenienza: se io utilizzo solo Flash adesso ma soprattutto in futuro potrei non riuscire a rendere il mio sito fruibile da tutti i miei potenziali clienti e allora mi adeguo.
Se loro, la NBC, la NBA e tutte le altre company non ritenessero che Silverlight sia un prodotto valido, per quanti soldi tu possa offrire, non avrebbero accettato perché prima di tutto viene la loro immagine e il loro business.

Sono tutte politiche commerciali dove microsoft "paga", tanto i soldi non gli mancano.

Adobe invece non paga, è ancora ferma all'epoca del baratto
Dai dai svegliati va.

Bè vedo che alla fine hai ammesso anche tu a cosa serve Silverlight

Guarda che non è mai stato in discussione che cosa sia in grado di fare Silverlight e per cosa sia utilizzabile, il problema è il come e il cosa c'è sotto e che fa la differenza tra un'applicazione di livello Enterprise e una no.
Ci sei o ci fai?

Siccome si occupa del come presentare il contenuto allora non è Enterprise? E i progettisti di applicazioni di quel tipo quando si spostano sul front-end secondo te cosa fanno, giocano a dadi?

E sempre secondo te se Adobe e Microsoft stanno spendendo milioni in R&D proprio in questo settore per cosa lo stanno facendo? Per bellezza?
La verità è che AJAX e le altre tecnologie RIA hanno rivoluzionato il modo di fare informazione, piaccia o no, tanto che si parla di Web 2.0 come di Enterprise 2.0.
Silverlight a differenza degli altri può essere impiegato senza alcuno sforzo aggiuntivo sia nell'uno che nell'altro, cosa che Flash/Flex non possono fare.
Punto.

microsoft rincorre, certo, è facile rincorrere quando ha soldi da buttare, che tanto sa di poter guadagnare, visto che non ti puoi rifiutare di comprare il suo SO quando compri un portatile, o spesso anche un pc desktop

Qui non commento nemmeno perché stai spostando il discorso su lidi non attinenti, mi limito solo a farti notare che stai facendo la reprimenda del libero mercato a MS quando stiamo analizzando un settore dove Adobe ha fatto fuori i propri concorrenti a suon di quattrini e prima dell'avvento della Microsoft stessa era per davvero dominato da un monopolista (altro che Windows), per cui falla finita.

bravo, vedo che allora qualcosa lo sai.
Però dovresti anche ricordare che Hibernate e JPA sono precedenti a Linq.
Microsoft insegue.

Cobol viene prima di Java...quindi Cobol è meglio?
E' fantastica questa annotazione cronologica per cui tu continui a ripetere che Microsoft insegue; e io continuo a dirti che parli di prodotti che non conosci perché LinQ è molto di più di un ORM (LinQToSQL può considerarsi l'ORM), visto che consente di manipolare basi di dati rimanendo ALL'INTERNO dello stack NET e con strutture semantiche built-in nel linguaggio C#, cosa che nessun'altra tecnologia è in grado di fare.

Fatti una cultura valà che ne hai bisogno.
http://weblogs.asp.net/scottgu/archi...ql-part-1.aspx
http://www.ictv.it/file/vedi/318/sud...ra-orm-e-linq/

se hai qualcosa da dire scrivilo negli appositi topic.

Qui già ci hai portato fuori topic dicendo che Silverlight è enterprise.

saluti.

:blabla: parla lui che ha infilato Python in discussioni che non c'entravano nulla tanto per menare il can per l'aia.
Ma vai a lavorare va

[Galileo]

Originariamente inviato da shinya

Te lo spiego io cos'è "un'applicazione enterprise seria".
Per capirlo, bisogna sapere che il 99% dei responsabili IT di quelle poche grosse aziende italiane che abbiamo sono uomini/donne con un'età superiore ai 50 anni, che hanno scritto il loro ultimo programma in COBOL 25 anni fa.

Questo quando va bene.
Quando va male, quel programma non l'hanno nemmeno mai scritto e sono capitati in quella posizione per amicizie/coincidenze/casualità o, ancora peggio, raccomandazioni all'italiana (che non sono le stesse raccomandazioni che avvengono all'estero).

Detto questo, bisogna anche sapere che queste sono le stesse persone che hanno l'ultima parola nella scelta delle tecnologie da utilizzare. Gli sviluppatori, NON scelgono le tecnologie con cui lavorare, nelle grandi aziende.

Succede quindi, il contrario di quello che sarebbe normale succedesse.

Bisogna poi sapere che i vecchi responsabili IT sono persone che non si aggiornano, non leggono almeno 1 libro tecnico al mese come consigliano quelli di The Pragmatic Programmer, non leggono reddit, non leggono i paper su da Lambda the Ultimate, e ovviamente, non programmano.

Le loro uniche fonti di informazione sono volantini pubblicitari di altre grandi aziende (Oracle, Sun, Microsoft, ecc...) che arrivano in ufficio, parlando di SOA e altre stronzate. Poi ci sono i commerciali delle aziende (o altre aziende partner) di cui sopra, che ogni tanto arrivano cercando di vendere qualche nuovo prodotto o funzionalità.

E' forte l'illusione che spinge a credere che legarsi ai prodotti di una grande azienda sia fonte di sicurezza, di stabilità, o peggio ancora, di supporto nel futuro. Dopotutto J2EE risponde a delle specifiche no? Quindi se ci atteniamo a quelle specifiche andrà tutto bene...

Questo è il motivo per cui nelle grandi aziende si usa Oracle, Websphere, ecc... E' più serio capisci? Sono venute qui delle PERSONE a parlarmene! In giacca e cravatta eh! Chi viene a parlarmi di Django? Nessuno, nella migliore delle ipotesi. Nella peggiore, può saltar fuori un consulente esterno in jeans che ti accenna velatamente (perchè i responsabili IT non solo non sanno di essere ignoranti, ma sono pure permalosi) ad altri modi di fare le stesse cose.

Ovviamente non devo star qua a confutare questo modo di ragionare, sappiamo tutti che sono stronzate.

questo post mi ha fatto pisciare, me lo incornicio e me lo stampo così quando vado nelle aziende lo lascio al dirigente di turno.

Si ride per non piangere naturalmente, perché la realtà che descrivi è tristemente vera; in Italia però, perché all'estero i project manager hanno l'età media dei ragazzi che terminano l'università da noi e con competenze che fanno, sempre mediamente, far venire i capelli bianchi dalla paura.
Non sono tutti delle cime ma 1) hanno almeno idea di cosa si parli quando scendi nel tecnico e quando parli di requisiti per esempio 2) se qualcosa non è chiaro hanno al tempo stesso l'umiltà di dire "no guarda non ti sto seguendo, ho capito però le linee principali, per il resto ti chiamo TizioCaio".

Questo è il concetto di "serietà" all'interno della "enterprise".
Potrei andare avanti per ore e scriverci un libro forse.

Avresti un potenziale compratore (per il libro intendo)

Sorvolo sul discorso del chi ce l'ha più lungo tra J2EE e Django e salcazzo cos'altro. Personalmente non mi piacciono gli ORM come concetto. SQL non è il problema, dal mio punto di vista.

Sono perfettamente d'accordo; dal mio punto di vista è molto più importante sviluppare secondo un modello che a seconda dei casi e dei requisiti, renda il più indipendenti possibili le varie logiche.
Sembra non si possa più fare a meno di un ORM, anche quando basterebbe un cazzo di file XML (e in progetti per le PMI spesso è così) e un mapping decisamente più leggero.
"Eh però abbiamo utilizzato un ORM che ci è costato 3 zeri"...poi vai a vedere il codice delle business entity e ti verrebbe voglia di tirare fuori l'accetta delle migliori occasioni.

Mi piace abbastanza J2EE fino a quando rimane a JSP/JSTL/Servlet. Quando si arriva a parlare di persistenza, di JPA, di EJB e compagnia, mi sembra di vedere la seconda stagione di Twin Peaks.

Poi la cosa che mi fa incazzare di questi framework è che tutta la documentazione che c'è in giro, parlo di Java perchè è ciò che uso quotidianamente, è il solito tutorial del tipo "Ecco, vedete com'è facile fare 'select * from table'? Questo esempio funziona benissimo con Apache Derby!".

Nell'enterprise NON esiste 'select * from table' e NON esiste Apache Derby!
Le informazioni sono sparse su db un pò qui e un pò là, su connessioni diverse, in posti diversi. E c'è Oracle. O Sql Server. O al massimo DB2. Basta.

Qualcuno mi fa vedere il codice per richiamare una stored procedure pl/sql su Oracle via JPA? Tipo una semplice procedura che mi ritorni un ref cursor con i risultati di una select (l'esempio non è campato per aria).

Ma vabbè mi fermo qua perchè poi si va sul gusto personale e non mi sembra il caso di aprire discussioni... anche se avrei qualche dubbio anche sull'approccio MVC su web...

Il discorso MVC (e lo svisceravamo giusto qualche tempo fa' io e un collega) è per me talis e qualis al Waterfall ed è un problema di aggiornamento/educazione alla novità.
C'è un modello di sviluppo che sta lì da eoni e allora usiamo quello. Il mondo intorno a noi cambia, i requisiti si evolvono, c'è bisogno di maggiore flessibilità e invece di parlare di metodologie agili si resta fossilizzati al Waterfall, che per altro colpevolmente viene insegnato dai dinosauri accademici come fosse IL metodo.
Con MVC =, io ormai nelle applicazioni web sono passato al DDD seppur con tanto timore iniziale, con enorme soddisfazione e senza alcun rimpianto.
I pattern (soprattutto architetturali) sono estremamente comodi ma se non sai quando usarli e come è peggio che non adottarli affatto, come tirarsi una martellata sui maroni.
The right tool for the right job


P.S.: Wikipedia rimuoverà il Singleton prima o poi? Chissà...

[k0nt3]

premessa:
JavaEE tecnicamente è equivalente alla miriade di alternative .NET/python/php/chipiùnehapiùnemetta
tipicamente in ambito aziendale si usano JavaEE o .NET perchè offrono maggiore supporto e inoltre si integrano in una piattaforma molto più vasta di quella che può offrire python per esempio.

Originariamente inviato da shinya

Sorvolo sul discorso del chi ce l'ha più lungo tra J2EE e Django e salcazzo cos'altro. Personalmente non mi piacciono gli ORM come concetto. SQL non è il problema, dal mio punto di vista.

non lo sarà dal tuo punto di vista, ma spesso lo è dal punto di vista della sicurezza, della robustezza e soprattutto della manutenibilità.

Originariamente inviato da shinya

Mi piace abbastanza J2EE fino a quando rimane a JSP/JSTL/Servlet. Quando si arriva a parlare di persistenza, di JPA, di EJB e compagnia, mi sembra di vedere la seconda stagione di Twin Peaks.

perchè cosa non va?

Originariamente inviato da shinya

Poi la cosa che mi fa incazzare di questi framework è che tutta la documentazione che c'è in giro, parlo di Java perchè è ciò che uso quotidianamente, è il solito tutorial del tipo "Ecco, vedete com'è facile fare 'select * from table'? Questo esempio funziona benissimo con Apache Derby!".

Nell'enterprise NON esiste 'select * from table' e NON esiste Apache Derby!
Le informazioni sono sparse su db un pò qui e un pò là, su connessioni diverse, in posti diversi. E c'è Oracle. O Sql Server. O al massimo DB2. Basta.

non so che documentazione hai guardato.. sicuramente non quella di SUN che è ultra completa

Originariamente inviato da shinya

Qualcuno mi fa vedere il codice per richiamare una stored procedure pl/sql su Oracle via JPA? Tipo una semplice procedura che mi ritorni un ref cursor con i risultati di una select (l'esempio non è campato per aria).

http://www.oracle.com/technology/pro...4.htm#BCFIJIIH
è ovvio che queste cose siano implementate come estensioni visto che JavaEE è pensato per essere multipiattaforma e le stored procedure non lo sono.
altrettanto ovvio è che usare pl/sql quando si può usare java vuol dire farsi del male. capisco però che siano state introdotte queste estensioni per motivi di compatibilità con sistemi legacy

Originariamente inviato da shinya

Ma vabbè mi fermo qua perchè poi si va sul gusto personale e non mi sembra il caso di aprire discussioni... anche se avrei qualche dubbio anche sull'approccio MVC su web...

l'approccio da usare dipende dall'applicazione. per un sito sul giardinaggio non mi sognerei nemmeno per sogno di usare MVC. ma siccome non si usa JavaEE in questi casi non c'è problema

[k0nt3]

Originariamente inviato da Galileo

Il discorso MVC (e lo svisceravamo giusto qualche tempo fa' io e un collega) è per me talis e qualis al Waterfall ed è un problema di aggiornamento/educazione alla novità.
C'è un modello di sviluppo che sta lì da eoni e allora usiamo quello. Il mondo intorno a noi cambia, i requisiti si evolvono, c'è bisogno di maggiore flessibilità e invece di parlare di metodologie agili si resta fossilizzati al Waterfall, che per altro colpevolmente viene insegnato dai dinosauri accademici come fosse IL metodo.
Con MVC =, io ormai nelle applicazioni web sono passato al DDD seppur con tanto timore iniziale, con enorme soddisfazione e senza alcun rimpianto.
I pattern (soprattutto architetturali) sono estremamente comodi ma se non sai quando usarli e come è peggio che non adottarli affatto, come tirarsi una martellata sui maroni.
The right tool for the right job

cosa c'è di male nel separare 3 componenti che fanno 3 cose totalmente scorrelate fra loro?
non capisco in che modo DDD possa escludere MVC, anzi in questo libro viene illustrato il DDD proprio usando MVC http://www.amazon.com/Domain-Driven-.../dp/0321125215

Part II of the book, introduces the building blocks of a Model-Driven Design. This section, as with the others, takes popular patterns from the Gamma, Flower, or others and applies them to the topic at hand - Model-Driven Design. In that aspect, the reader can easily follow the text and relate to topic at hand. Evans uses the ever-popular Model-View-Controller (MVC) design pattern to get things going in part II. He then goes off to explain why the layered architecture approach is an important aspect of a Domain-Driven Design and how it would makes things simpler:

"[Layered Architecture] allows a model to evolve to be rich enough and clear enough to capture essential business knowledge and put it to work."

[shinya]

Originariamente inviato da k0nt3

non lo sarà dal tuo punto di vista, ma spesso lo è dal punto di vista della sicurezza, della robustezza e soprattutto della manutenibilità.

Se parli di SQL Injection, basta usare PreparedStatement. Per quanto riguarda la manuntenibilità, ho dei dubbi sul fatto che una serie di classi che rappresentano relazioni 1:N, N:M, ecc... siano più facili da gestire di una procedura pl/sql (per dire). Ho dei dubbi sul tenere tutta la business logic sull'application server, dato che il db, per quanto lo si voglia utilizzare solo come contenitore di dati (ma un db moderno come Oracle è molto di più), contiene già nella struttura delle tabelle una parte di business logic (sotto forma di relazioni tra entità, constraint, vincoli vari, trigger, ecc).

Non dico sia sbagliato in assoluto come approccio, dico che ho dei dubbi.

Per quanto riguarda gli eventuali problemi di performance, non saprei nemmeno qui. Gli ORM altro non fanno che generare codice del quale non conosci l'execution plan.

Originariamente inviato da k0nt3

perchè cosa non va?

Personalmente ritengo le specifiche troppo complesse per quel che si vuole ottenere.

Originariamente inviato da k0nt3

http://www.oracle.com/technology/pro...4.htm#BCFIJIIH
è ovvio che queste cose siano implementate come estensioni visto che JavaEE è pensato per essere multipiattaforma e le stored procedure non lo sono.
altrettanto ovvio è che usare pl/sql quando si può usare java vuol dire farsi del male. capisco però che siano state introdotte queste estensioni per motivi di compatibilità con sistemi legacy

Ci sono alcuni problemi con il link e con quello che dici.
1) è Toplink, un prodotto Oracle. A parte gli eventuali costi, non so se si paga e quanto, questo mi porta al punto 2...
2) non è affatto ovvio che le chiamate a stored procedure siano implementate come estensioni, perchè in JDBC già lo posso fare senza estensioni proprietarie. Perchè con JPA no?
3) non è ovvio nemmeno che usare pl/sql al posto di java sia da masochisti. Per quello che fa, pl/sql è MOLTO comodo. Quando hai a che fare con operazioni con il db, pl/sql batte java 100:1 come produttività.
Ci sono i pro e i contro, come in tutte le cose.

Originariamente inviato da k0nt3

l'approccio da usare dipende dall'applicazione. per un sito di giardinaggio non mi sognerei nemmeno per sogno di usare MVC. ma siccome non si usa JavaEE in questi casi non c'è problema

No i miei problemi con MVC su web sono proprio alla radice. Non c'è una definizione precisa. Si è preso un concetto nato per un'altra cosa, e ognuno l'ha adattato. Si sono prese tre parole, le si sono appiccicate su tre parti dell'applicazione e voilà, MVC! Sono in molti a mettere in dubbio il paradigma MVC su web.

Esempio: http://www.sitepoint.com/blogs/2005/...oil-and-water/

[cdimauro]

Originariamente inviato da k0nt3

premessa:
JavaEE tecnicamente è equivalente alla miriade di alternative .NET/python/php/chipiùnehapiùnemetta
tipicamente in ambito aziendale si usano JavaEE o .NET perchè offrono maggiore supporto e inoltre si integrano in una piattaforma molto più vasta di quella che può offrire python per esempio.

Sarà proprio per questo che colossi come Google, YouTube, Yahoo, MS, utilizzano Python.

[shinya]

Originariamente inviato da k0nt3

premessa:
JavaEE tecnicamente è equivalente alla miriade di alternative .NET/python/php/chipiùnehapiùnemetta
tipicamente in ambito aziendale si usano JavaEE o .NET perchè offrono maggiore supporto e inoltre si integrano in una piattaforma molto più vasta di quella che può offrire python per esempio.

Questa è l'illusione di cui parlavo prima.

[mdipierro]

Sento mio dovere definire cosa sia una "enterise application" per me dato che definisco web2py un "enterprise web framework".

Premetto che sono molto d'accordo con le osservazioni di shinya.

Una applicazione "enterprise" e' una applicatione che si prefigge come utente target una azienda (che puo' essere piccola o grande) e non un hacker or un amatore. Nel caso di J2EE e Oracle il target a' una grande azienda in cui il problema principale e' distribuire il lavoro di sviluppo tra molti dipendenti con abilita' techniche medie e discutibili e preferisce comprare componenti invece di svilupparli. Nel caso di web2py il target e' una piccola azienda the cerca di minimizzare i costi di sviluppo e mantenimento.

Cosa distingue una applicazione "enterprise" rispetto a una "non-enterprise"? Per me la usability, la facilita' di installazione, la documentazione, e la stabilita'. Una applicazione che non e' in sync con la documentazione, che rischiede agli sviluppatori di leggere il codice sorgente, o che rompe la backward compatility ad ogni release non e' "enterprise". Per questo Django non e' enterprise ready. Forse Django lo sara' in versione 1.0. J2EE and ASP.NET sono enterprise ready anche se propongono modelly di Software Engineering the sono obsoleti ed hanno una sintassi troppo prolissa rispetto a qualunque Python framework.

[cdimauro]

Come ho già detto, Django sarà stabile a livello di API a partire dalla versione 1.0.

P.S. Comunque mi sto studiando web2py, che trovo molto interessante. Ho anche passato il link ad alcuni miei colleghi per valutarlo come eventuale alternativa a Django.

[k0nt3]

Originariamente inviato da shinya

Se parli di SQL Injection, basta usare PreparedStatement. Per quanto riguarda la manuntenibilità, ho dei dubbi sul fatto che una serie di classi che rappresentano relazioni 1:N, N:M, ecc... siano più facili da gestire di una procedura pl/sql (per dire). Ho dei dubbi sul tenere tutta la business logic sull'application server, dato che il db, per quanto lo si voglia utilizzare solo come contenitore di dati (ma un db moderno come Oracle è molto di più), contiene già nella struttura delle tabelle una parte di business logic (sotto forma di relazioni tra entità, constraint, vincoli vari, trigger, ecc).

Non dico sia sbagliato in assoluto come approccio, dico che ho dei dubbi.

i dubbi sono sacrosanti, però non c'è alcun dubbio sul fatto che in query molto complesse è difficile ottenere un certo livello di manutenibilità con SQL.
mettere nel DB parte della logica applicativa potrebbe essere utile come potrebbe essere dannoso. io tenderei a separare la gestione dei dati dalla logica applicativa non perchè MVC sia la bibbia, ma perchè il risultato sarebbe più semplice da gestire.
usare i vincoli nel DB è utile per migliorare la robustezza dell'applicazione, ma non significa includere la logica applicativa nel DB, stiamo sempre parlando di descrizione dei dati (in ogni caso il confine tra descrizione dei dati e logica applicativa non è netto).

Originariamente inviato da shinya

Per quanto riguarda gli eventuali problemi di performance, non saprei nemmeno qui. Gli ORM altro non fanno che generare codice del quale non conosci l'execution plan.

è normale non conoscere l'execution plan, anche per quanto riguarda le query SQL è così.
perchè in questo caso il computer è in grado di ottimizzare il codice meglio di qualunque programmatore.

Originariamente inviato da shinya

Personalmente ritengo le specifiche troppo complesse per quel che si vuole ottenere.

forse per quello che vuoi ottenere te
si vede che JavaEE non è adatto alla tua applicazione, niente di male. nessuno ha detto che JavaEE va usato per tutto.

Originariamente inviato da shinya

Ci sono alcuni problemi con il link e con quello che dici.
1) è Toplink, un prodotto Oracle. A parte gli eventuali costi, non so se si paga e quanto, questo mi porta al punto 2...
2) non è affatto ovvio che le chiamate a stored procedure siano implementate come estensioni, perchè in JDBC già lo posso fare senza estensioni proprietarie. Perchè con JPA no?
3) non è ovvio nemmeno che usare pl/sql al posto di java sia da masochisti. Per quello che fa, pl/sql è MOLTO comodo. Quando hai a che fare con operazioni con il db, pl/sql batte java 100:1 come produttività.
Ci sono i pro e i contro, come in tutte le cose.

1) è irrilevante il fatto che sia un prodotto di oracle, JavaEE è solamente una specifica che chiunque può implementare. nella fattispecie TopLink implementa le specifiche JPA. si può scaricare la versione Essentials che è gratuita oltre che opensource e utilizzabile nei limiti della licenza CDDL
2) in effetti è strano che in JDBC si possa fare mentre in JPA no.. forse è una scelta che hanno fatto per scoraggiare l'uso di stored procedure in questo ambito. rimane comunque la possibilità di usare estensioni o JDBC stesso
3) sicuramente in qualche caso andrà meglio pl/sql, ma in generale no. è un linguaggio procedurale con tutti i limiti del caso.. inoltre non è portabile.

Originariamente inviato da shinya

No i miei problemi con MVC su web sono proprio alla radice. Non c'è una definizione precisa. Si è preso un concetto nato per un'altra cosa, e ognuno l'ha adattato. Si sono prese tre parole, le si sono appiccicate su tre parti dell'applicazione e voilà, MVC! Sono in molti a mettere in dubbio il paradigma MVC su web.

Esempio: http://www.sitepoint.com/blogs/2005/...oil-and-water/

c'è differenza tra usare MVC e usare male MVC
cosa c'è di male nel separare la gestione dei dati dalla logica applicativa e dalla modalità con cui i dati vengono presentati all'utente?
nel web questo pattern è molto utilizzato proprio perchè quasi sempre esistono queste 3 componenti.
quali sarebbero i problemi nell'utilizzarlo?

[k0nt3]

Originariamente inviato da cdimauro

Sarà proprio per questo che colossi come Google, YouTube, Yahoo, MS, utilizzano Python.

google e youtube coincidono
probabilmente questi colossi hanno abbastanza risorse interne per poter sopperire all'eventuale mancanza di supporto.
mi sembra ovvio che python non possa fornire lo stesso supporto di sun, non è mica colpa del linguaggio, ma dell'azienda che ci sta dietro (nel caso di python una comunità)

[k0nt3]

Originariamente inviato da shinya

Questa è l'illusione di cui parlavo prima.

intendi per il supporto o per la vastità dei framework java e .NET rispetto a python?

[cdimauro]

Originariamente inviato da k0nt3

google e youtube coincidono

Coincidono ADESSO, non quando hanno iniziato a utilizzare Python. L'hanno fatto in maniera indipendente.

probabilmente questi colossi hanno abbastanza risorse interne per poter sopperire all'eventuale mancanza di supporto.

Questo lo puoi dire ADESSO che sono dei colossi, non quando hanno iniziato la loro attività.

mi sembra ovvio che python non possa fornire lo stesso supporto di sun, non è mica colpa del linguaggio, ma dell'azienda che ci sta dietro (nel caso di python una comunità)

Indubbiamente: Sun il supporto te lo fa anche pagare.

Comunque Python ha un'ottima comunità e ci si riesce ad arrangiare lo stesso. Poi realtà come Google aiutano anche economicamente alcuni progetti e lo sviluppo stesso del linguaggio (Guido viene pagato per metà del suo tempo per questo motivo, ad esempio).

[Galileo]

Premessa: hai una vaga di cosa sia il DDD oppure hai letto la documentazione/libri di Evans e applicato nelle tue applicazioni?

Originariamente inviato da k0nt3

cosa c'è di male nel separare 3 componenti che fanno 3 cose totalmente scorrelate fra loro?

Perché invece nel DDD le 3 componenti sono unite, secondo te? No fammi capire, perché non riesco a seguire la tua obiezione.

non capisco in che modo DDD possa escludere MVC, anzi in questo libro viene illustrato il DDD proprio usando MVC http://www.amazon.com/Domain-Driven-.../dp/0321125215

Non ci siamo.
Partendo dal presupposto che un commento su una recensione di Amazon non significa nulla per cui la obiezione, formulata in questo modo, ha un valore pressoché zero, il problema è un altro.
Stai confondendo il dominio.
Si stava parlando di pattern architetturali (in questo contesto c'è il confronto tra MVC e DDD), non di design pattern (dove il confronto semplicemente non sussiste perché il DDD non rientra nella categoria).

Se li vediamo asimmetricamente allora possiamo combinarli, altrimenti no come ho spiegato sopra.
Il problema è che spesso viene impiegato questo monolite anche quando i requisiti non richiedono questo livello di complessità (e mi riallaccio a shinya); io preferisco essere agile, il che si sposa molto bene lavorando con il DDD.
Questo non significa che tutto quel che viene costruito con MVC faccia schifo o che i tool messi a disposizione siano mediocri, ASP.NET MVC ad esempio, che si sposa piuttosto bene con XP.

[k0nt3]

Originariamente inviato da Galileo

Perché invece nel DDD le 3 componenti sono unite, secondo te? No fammi capire, perché non riesco a seguire la tua obiezione.

e dove sta scritto?
quello a cui fai riferimento è quello che evans chiama Smart UI, ma non c'entra niente con il DDD. semplicemente dice che il DDD in linea di principio si può applicare con il pattern MVC, senza pattern MVC (Smart UI) o con una qualsiasi via di mezzo, a seconda della convenienza. infatti MVC non va mica applicato sempre.

Originariamente inviato da Galileo

Non ci siamo.
Partendo dal presupposto che un commento su una recensione di Amazon non significa nulla per cui la obiezione, formulata in questo modo, ha un valore pressoché zero, il problema è un altro.
Stai confondendo il dominio.
Si stava parlando di pattern architetturali (in questo contesto c'è il confronto tra MVC e DDD), non di design pattern (dove il confronto semplicemente non sussiste perché il DDD non rientra nella categoria).

appunto! allora come fai a dire che preferisci DDD a MVC se uno non esclude l'altro?

Originariamente inviato da Galileo

Se li vediamo asimmetricamente allora possiamo combinarli, altrimenti no come ho spiegato sopra.

io li vedo con due occhi.. non so te

Originariamente inviato da Galileo

Il problema è che spesso viene impiegato questo monolite anche quando i requisiti non richiedono questo livello di complessità (e mi riallaccio a shinya); io preferisco essere agile, il che si sposa molto bene lavorando con il DDD.
Questo non significa che tutto quel che viene costruito con MVC faccia schifo o che i tool messi a disposizione siano mediocri, ASP.NET MVC ad esempio, che si sposa piuttosto bene con XP.

MVC è uno strumento che va usato quando serve, ma non è affatto superato e nel libro di evans non viene detto da nessuna parte.
come ho già detto se devo fare un sito sul giardinaggio non lo uso di certo.

[Sciakallo]

Originariamente inviato da Sciakallo

Raga non vi infiammate troppo eh?
Comunque innanzitutto ringrazio tutti per i consigli...volendo iniziare con web2py ci sono documentazioni/guide in italiano?
Stesso discorso per il linguaggio in se per se...

Rinnovo le mie domande sperando ke non si vada ankora OT

[cdimauro]

Scusami. Rispondo io, per quel che ho avuto modo di vedere.

Documentazione, guida, ed esempi sono tutti in inglese, ma godibilissimi e semplici da digerire. Non dovresti avere difficoltà, e comunque lo sviluppatore è italiano e se dovessi avere bisogno penso che una mano te la darà sicuramente.

La mia impressione è che si tratti di un eccellente prodotto, ed è la stessa cosa idea che s'è fatto un mio collega. Ovviamente le idee si devono anche consolidare, per cui bisogna sperimentare e farci qualche progetto per acquisire know-how sullo strumento e comprenderne le potenzialità.

Per Python, invece, trovi un eccellente libro per imparare a programmare qui.
Inoltre se hai dubbi apri un thread in questo forum, e penso che non mancheranno le risposte (nei limiti del possibile e delle conoscenze).

[Sciakallo]

Grazie per la risposta...ho dato un'occhio veloce a quel manuale..ma sbaglio o non c'è l'interfaccia grafica nella programmazione phyton in stile c++?

[nico159]

Originariamente inviato da Sciakallo

Grazie per la risposta...ho dato un'occhio veloce a quel manuale..ma sbaglio o non c'è l'interfaccia grafica nella programmazione phyton in stile c++?

Come no, ci sono le QT, che probabilmente è il miglior framework per scrivere applicazioni grafiche che esista...e che puoi sfruttare alla grande con Python (attento però, nel caso intendessi scrivere software closed, devi acquistarne la licenza )