Quali fattori considerare quando si sceglie il runtime / lingua per le applicazioni desktop di Windows?

10

I miei utenti hanno tutti Windows. Alcuni usano Linux o Mac, ma se lo fanno sono generalmente capaci di usare qualcosa come Mono, Wine, Parallels o dual-boot.

Il mio team di sviluppo (me compreso) ha una vasta esperienza sia per iscritto Applicazioni Swing in Java e Windows Form in C #. "Estensivo" significa che abbiamo sviluppato e spedito oltre tre applicazioni su entrambi i runtime. Le applicazioni sono applicazioni di analisi tecnica, così delicate sull'interazione del database, ma pesanti sull'interfaccia utente personalizzata e sulle dimensioni del set di dati.

Stiamo arrivando al punto in cui vogliamo davvero prendere una decisione su quale piattaforma mettere a fuoco da ora in poi, dato che sta diventando un peso da sostenere entrambi (se lavori per mezzo anno in Swing è troppa fatica per abituarsi a Windows Form e viceversa) e vogliamo che tutti nel nostro team siano in grado di lavorare su tutte le nostre applicazioni.

  • Generalmente, Windows Form richiede meno lavoro per rendere riconoscibili le applicazioni Windows. Nessuna quantità di skin e controlli personalizzati in Java l'hanno risolta nel corso degli anni. Allo stesso tempo, non abbiamo mai avuto un cliente che non potesse utilizzare le applicazioni Swing.
  • Java aveva un ecosistema molto più ricco in termini di librerie e strumenti di compilazione automatici, ma sta cambiando rapidamente (Java non sta andando giù, è più che .NET sta recuperando).
  • Per i rari casi in cui è preferibile la piattaforma multipiattaforma, Java batte le mani su .NET. Mono è meraviglioso, ma è ancora più utile di Java.

Se scegliamo .NET, possiamo iniziare a concentrarci su WPF, ma anche iniziare a usare F #. Se scegliamo Java, possiamo iniziare a concentrarci su RCP, ma anche iniziare a usare Scala.

Qualcuno ha dovuto prendere una decisione simile? Se sì, che cosa è stato e cosa ti ha influenzato di più? Qualche preoccupazione principale mi manca?

(Nota: ci sono già domande simili su Programmers.SE, ma sono o non costruttive o da una diversa angolazione.)

    
posta Deckard 16.05.2011 - 08:01
fonte

6 risposte

7

Siamo andati per Java (Swing) più alcune parti native tramite JNI. Mentre la domanda commerciale di multipiattaforma può essere marginale oggi, la situazione potrebbe essere diversa tra 5 anni, e il ciclo di vita dell'app (un'app di misurazione scientifica) sarà più simile a 10+ anni (il suo predecessore C ++, ancora usato oggi, ha file sorgente del 1991). Come hai scritto, Java batte .NET in ambienti non Windows, e se dovessimo mai passare da Windows, è solo una questione di ricompilare alcune parti native, magari perfezionare l'aspetto della GUI e controllare che tutto funziona.

Se sei sicuro che sarai solo Windows, e la tua app vivrà solo pochi anni, allora .NET potrebbe essere preferito - sembra e si comporta più come un'app nativa perché lo è. Ma come investimento a lungo termine, mi fido di più di Java. L'oscillazione può sembrare un po 'meno perfetta, il tempo di avvio potrebbe essere più lungo, tutto è un po' non ottimale a causa del livello di astrazione multipiattaforma, ma almeno "funziona".

    
risposta data 16.05.2011 - 09:27
fonte
4

Una cosa che dovresti prendere in considerazione è il progetto IKVM che ti permette di usare il codice Java in un mondo .NET. È quindi possibile ottenere i vantaggi di un back-end Java, mentre - per quanto ne so - è possibile avere un frontman sottile in Swing o WinForms.

link

Ho sentito che altri hanno usato questo per usare una libreria di connessione open source scritta in Java da .NET invece di dover usare l'ingombrante versione .NET.

    
risposta data 19.06.2011 - 15:54
fonte
3

C'è una risorsa su MSDN che potrebbe esserti utile: link .

Se vai in fondo alla pagina troverai una serie di white paper che mettono a confronto Java e .NET concettualmente. Ovviamente visto che è su MSDN è polarizzato verso .NET, ma le risorse sono comunque abbastanza utili.

    
risposta data 17.05.2011 - 01:43
fonte
1

Ho riflettuto anche su questo, e ho trovato che la risposta dipende dal tipo di progetto e da cosa puoi prevederlo.

A volte, la creazione di One Codebase per il servizio di tutte le piattaforme è una buona cosa: si ottiene un certo livello di coerenza dell'interfaccia utente con un codice complessivo inferiore. Penso che i vantaggi e gli svantaggi siano ovvi, quindi lo salterò.

Ci sono momenti in cui avere 2 basi di codice scritte in modo nativo è meglio. Se, per esempio, scrivere la tua app in WPF è elegante per .NET, e scriverlo, per esempio, Cocoa è elegante per Mac OS, il codice risultante potrebbe essere effettivamente più piccolo rispetto all'uso, ad esempio, di Java o Mono (che non ha WPF). In tal caso, potresti ottenere risultati migliori con meno codice.

Un'ultima considerazione è forse fare la tua app come un'applicazione HTML5 o anche un'estensione di Chrome, ma potrebbe anche essere un campo a sinistra.

    
risposta data 16.05.2011 - 21:15
fonte
1

Hai considerato Silverlight ? Può essere una buona scelta per costruire anche l'applicazione Windows Desktop (da SL4 +) e lavorare bene su Mac.

    
risposta data 23.06.2011 - 11:18
fonte
1

Come sviluppatore Java a tempo pieno posso dirti che mentre la compatibilità multipiattaforma è sorprendente, ogni integrazione nativa è un inferno .

Ho sempre avuto molti problemi, e talvolta fallito, su questo terreno. Potresti non averne bisogno, ma a volte mi inciampo e di solito mi fa male.

  • L'integrazione con COM è dolorosa e COM + a volte è impossibile (settimane sprecate che cercano di farlo funzionare con l'API di Windows Tablet).
  • L'interazione con l'hardware può far male. A volte l'API è disponibile solo su una piattaforma (ad esempio, integrazione fotocamera / scanner).
  • Anche l'interazione con le applicazioni locali può far male. Ho detto che il dolore COM? Bene, un altro modo (che abbiamo effettivamente usato) è stato quello di generare ed eseguire script VBS che lanciano un'applicazione Windows come MapPoint o qualche app di mapping proprietaria e la alimentano con i dati.
  • Anche l'installazione e l'integrazione desktop (scorciatoie, disinstallazione, menu di avvio) possono far male. Web Start è molto inaffidabile. Le alternative ti costano caro o mancano alcune funzionalità (come la distribuzione degli aggiornamenti).

Non fraintendermi. Sono uno sviluppatore Java e non intendo fiammeggiare. Dico solo che se sospetti di aver bisogno di uno dei precedenti, può farti male e potresti stare meglio con .net . Almeno è un argomento che dovresti prendere in considerazione.

    
risposta data 23.06.2011 - 11:36
fonte

Leggi altre domande sui tag