Percorso inverso, da .NET a Java

di il
23 risposte

Percorso inverso, da .NET a Java

Sono un programmatore .NET e sviluppo in questo ambiente da quando esiste.

Ora vorrei, per poter proporre la mia candidatura ad alcune aziende della zona, imparare Java.

Quello che cerco è uno o più manuali, meglio se in italiano per velocizzare lo studio, che tratti la programmazione three tier e four tier e che non parta dalla spiegazione della programmazione ad oggetti.

Cosa consigliate?

23 Risposte

  • Re: Percorso inverso, da .NET a Java

    Sulla tecnologia Java-EE non credo ci siano libri in italiano, ma non ci giurerei. Di solito vado su testi in inglese che sono quelli piu' esaustivi.
  • Re: Percorso inverso, da .NET a Java

    In inglese cosa consigliereste?
  • Re: Percorso inverso, da .NET a Java

    Uno potrebbe essere questo: http://www.amazon.com/dp/1430219548/?tag=stackoverfl08-20
    Un altro:
  • Re: Percorso inverso, da .NET a Java

    J2ee e' java piu' un sacco di api aggiuntive:

    jdbc: accesso ai db
    jms: invio e ricezione messaggi
    jpa/jdo: mapping oggetti java tabelle di db
    ejb: versione piu' complicata della precedente
    jsp: pagine html + java
    faces: versione piu' complicata della precedente
    portlet: jsp + un bel framework
    jta: per le transazioni,
    xml: parsing documenti xml
    rmi: remote method invocation
    javamail: e-mail
    ... (e sono solo quelle che mi ricordo in questo momento)
    un sacco di altre...

    e ne compaiono di nuove in continuazione

    per ogni argomento la oreilly ha un ottimo testo.

    il problema e' che sono tante, e anche se non complesse singolarmente, ogn'una richiede almeno una settimana per essere digerita (studiata l'api, installata un'implementazione, e fatta qualche prova).

    Ti conviene iniziare con java, xml e jdbc.
    Poi le altre le selezionerai in base alle necessita'

    Ultima cosa: impara l'inglese.
    Anzi: come prima!!
  • Re: Percorso inverso, da .NET a Java

    migliorabile ha scritto:


    j2ee e' java piu' un sacco di api aggiuntive:

    jdbc: accesso ai db
    jms: invio e ricezione messaggi
    jpa/jdo: mapping oggetti java tabelle di db
    ejb: versione piu' complicata della precedente
    jsp: pagine html + java
    faces: versione piu' complicata della precedente
    portlet: jsp + un bel framework
    jta: per le transazioni,
    xml: parsing documenti xml
    rmi: remote method invocation
    javamail: e-mail
    ... (e sono solo quelle che mi ricordo in questo momento)
    un sacco di altre...

    e ne compaiono di nuove in continuazione

    per ogni argomento la oreilly ha un ottimo testo.

    il problema e' che sono tante, e anche se non complesse singolarmente, ogn'una richiede almeno una settimana per essere digerita (studiata l'api, installata un'implementazione, e fatta qualche prova).

    Ti conviene iniziare con java, xml e jdbc.
    Poi le altre le selezionerai in base alle necessita'

    Ultima cosa: impara l'inglese.
    Anzi: come prima!!

    Grazie mille.
    L'inglese lo so, mi sono anche sparato diversi esami di certificazione Microsoft, Cisco e HP tutti in inglese ma è ovvio che leggere qualcosa nella tua lingua è un'altra cosa in termini di velocità.

    Quello che mi interessa di Java è, oltre alla mera sintassi, capire come sviluppare due tipi di applicazioni.

    Il primo tipo è client server con database annesso quindi un client che fa richiesta ad un servizio, (magari SOAP?), il servizio stesso e un framework che mi astragga dal database (mi pare di capire che EJB è l'equivalente del Microsoft Entity Framework, o sbaglio?).

    Il secondo tipo sono le applicazioni embedded, mi interessa molto ad esempio il discorso Raspberry Pi, non so se qualcuno ha esperienza.

    Un'altra domanda, J2EE è compatibile nella stessa maniera con Windows e Linux? Ho sentito pareri discordanti in merito...
  • Re: Percorso inverso, da .NET a Java

    Il primo tipo è client server con database annesso quindi un client che fa richiesta ad un servizio, (magari SOAP?), il servizio stesso e un framework che mi astragga dal database (mi pare di capire che EJB è l'equivalente del Microsoft Entity Framework, o sbaglio?).
    No, in Java-EE e' il JPA.
  • Re: Percorso inverso, da .NET a Java

    A parte la grafica, java funziona esattamente nello stesso modo su tutte le piattaforme
  • Re: Percorso inverso, da .NET a Java

    Comunque stai mettendo in campo in un'unico calderone un sacco di argomenti. Ti conviene affrontarli uno alla volta
  • Re: Percorso inverso, da .NET a Java

    Concordo con migliorabile. Devi avere ben chiaro quale sara' il tuo target, su quale tipo di applicazione ti vuoi orientare. Altrimenti l'ecosistema di Java/Java-EE e' talmente vasto che rischi di perderti senza concludere niente.
  • Re: Percorso inverso, da .NET a Java

    morellik ha scritto:


    Il primo tipo è client server con database annesso quindi un client che fa richiesta ad un servizio, (magari SOAP?), il servizio stesso e un framework che mi astragga dal database (mi pare di capire che EJB è l'equivalente del Microsoft Entity Framework, o sbaglio?).
    No, in Java-EE e' il JPA.
    E' peggio di cosi

    Sono tutti ORM (Object Relational Mapping). Le API standard di Java sono

    alla base c'e JDBC

    Quindi ci sono 2 API

    JDO: Java data object (la piu' vecchia)
    JPA: java Persistent Architecture (la piu' recente)

    Poi ci sono gli EJB, ma sono pesanti e complicati

    Poi ci sono le miriadi di implementazioni piu' o meno buone di JDo, JPA, EJB e ORM in generale, tra cui la piu' famosa e' sicuramente Hibernate.
    Io ho usato l'allora JPOX, ora Kodo, implementazione di JDO (ed ora anche di JPA) quando ancora era OpenSource e l'avevo esteso per gestire le colonne XML e fare query usando XPath. Ottima libreria.

    Anche gli ORM sono belli complicati: come al solito, attenzione al markkketttting.
    Sposti le rogne dall'SQL alla scrittura dei file di configurazione e all'impossibilita' di fare query ottimizate. Magari ti serve il valore di un'unica colonna, ma lui comunque ti estrare l'intero record perche' deve creare in memoria l'oggetto Java.
  • Re: Percorso inverso, da .NET a Java

    migliorabile ha scritto:


    morellik ha scritto:


    Il primo tipo è client server con database annesso quindi un client che fa richiesta ad un servizio, (magari SOAP?), il servizio stesso e un framework che mi astragga dal database (mi pare di capire che EJB è l'equivalente del Microsoft Entity Framework, o sbaglio?).
    No, in Java-EE e' il JPA.
    E' peggio di cosi

    Sono tutti ORM (Object Relational Mapping). Le API standard di Java sono

    alla base c'e JDBC

    Quindi ci sono 2 API

    JDO: Java data object (la piu' vecchia)
    JPA: java Persistent Architecture (la piu' recente)

    Poi ci sono gli EJB, ma sono pesanti e complicati

    Poi ci sono le miriadi di implementazioni piu' o meno buone di JDo, JPA, EJB e ORM in generale, tra cui la piu' famosa e' sicuramente Hibernate.
    Io ho usato l'allora JPOX, ora Kodo, implementazione di JDO (ed ora anche di JPA) quando ancora era OpenSource e l'avevo esteso per gestire le colonne XML e fare query usando XPath. Ottima libreria.

    Anche gli ORM sono belli complicati: come al solito, attenzione al markkketttting.
    Sposti le rogne dall'SQL alla scrittura dei file di configurazione e all'impossibilita' di fare query ottimizate. Magari ti serve il valore di un'unica colonna, ma lui comunque ti estrare l'intero record perche' deve creare in memoria l'oggetto Java.
    Già mi sta passando la voglia

    Nel mondo .NET queste tecnologie arrivano più tardi ma quando arrivano sono mature, stabili e ottimizzate.

    Per il mondo embedded invece qualcuno ha esperienza?
  • Re: Percorso inverso, da .NET a Java

    Ni: .NET e' nato dopo Java.
    I migliori software sono quelli che da Java sono stati portati sotto .NET

    In generale, a mio avviso, .NET e' molto piu' raffazonato di Java. Approssimativo, con stil diversi di implementazione abastanza evidenti.

    In Java esiste ben chiaro il concetto di API, di JSR (Java Specification Request) e di implementazione.
    Ad esempio: in Java ci sono innumerevoli implementazione di parser XML, tutti implementano le stesse API. Sostituire un'implementazione con un'altra in un'applicazione e' solo una questione di configurazione. L'applicazione rimane la stessa.

    In .NET questo non esiste, o almeno e' stato aggiunto solo dopo.
    Non puoi utilizzare diverse implementazioni di un parse XML. Se cambi il parser, devi cambiare anche il codice.

    In java l'accesso ai DB viene fatto attraverso JDBC.
    L'accesso ad un database o ad unaltro e' solo una questione di cambiare una stringa:

    Driver.createConnection("jdbc:mysq://localhost:3306/mydb")
    Driver.createConnection("jdbc: postgresql://localhost:5432/mydb")

    Non serve sapere da quali classi e' composta l'implementazione.
    In .NET, hai la SQLConnection, .. la OracleConnection, ...
    O accedi a SQLServer OPPURE ad Oracle. Ma non puoi deciderlo da configurazione.

    Dopo essersi accorti di questa castronata, hanno introdotto la DbConnection ...

    Ma non c'e' un sistema automatico di scelta dell'implementazione a partire da una stringa di configurazione. Me la sono dovuta implementare per conto mio.
  • Re: Percorso inverso, da .NET a Java

    Io ti consiglierei i due libri della collana Core Java 2 .Sono due volumi ben nutriti e ben spiegati
    di horstmann e cornell e li trovi anch ein italiano
    Io ho appena preso il volume 2 tecniche avanzate su hoepli
    Il volume 1 non credo tu ne abbia bisogno , alla fine sono cose che sai gia come la sintassi del linguaggio , classi , interfacce , awt (window form) ed altro lo puoi reperire tranquillamente sul web
    Il core java 2 volume 2 invece e' piu avanzato
    Per lo sviluppo ti consiglio Netbeans 7.4 e poi per il database il PostgreeSQL , molto intuitivo e veloce , non come sql express ...che devi sempre invocare santi ect
    ciao
  • Re: Percorso inverso, da .NET a Java

    Ho paura che i due libri siano sempre troppo Java SE oriented. La tecnologia .NET mi sa che si avvicina piu' a Java EE. IMHO.
Devi accedere o registrarti per scrivere nel forum
23 risposte