2013-01-16 2 views
5

So che ci sono molte domande Qt vs MFC, ma cercherò di essere molto specifico.L'utilizzo di Qt in una grande app per Windows solo per MFC accelera lo sviluppo?

Abbiamo una grande (10 anni di sviluppo) applicazione MFC C++ per l'industria di nicchia. Dovrebbe rimanere solo per Windows e solo in inglese per sempre. Ma abbiamo bisogno di aggiungere una serie di nuovi GUI disegnati da designer e controlli GUI (finestre di dialogo, pulsanti, liste personalizzate, ...).

Possiamo assumere 1 o 2 nuovi sviluppatori GUI per creare queste nuove interfacce, quindi possiamo permetterci di scegliere una tecnologia diversa da MFC.

Qt sembra più promettente e adatto per funzionare parallelamente a MFC (oh, no, non stiamo ridisegnando l'app da zero).

Sembra che i vantaggi di Qt più citati siano irrilevanti: sviluppo multipiattaforma, facile internazionalizzazione, opensource, librerie non GUI (non è necessario il collegamento in rete e la maggior parte delle altre funzionalità è già implementata).

Ma Qt è anche famoso per il suo buon design OO e ha recentemente introdotto QtQuick. Mi piacerebbe dare una possibilità, quindi le domande sono

  • In un solo per Windows progetto commerciale, quali sono i vantaggi del passaggio al substantional MFC + Qt dalla pura MFC, che vale la pena di imparare Qt, integrandolo nel nostro processo di compilazione/implementazione e magari pagando una licenza commerciale?
  • In particolare, velocizzerà lo sviluppo se costruiamo nuove GUI in Qt e le incorporiamo nell'app tramite QWinWidget?
+0

Sarei curioso di sapere come si eseguono MFC e Qt insieme, avrei pensato impossibile: ci può essere un solo ciclo di messaggi. –

+2

Tutti i miei sensi di ragno mi stanno dicendo che questa è una cattiva idea, è quasi garantito che impiegherete più sforzo di quanto valga la pena mantenere uno stato coerente tra MFC e QT. – Ylisar

+1

@MarkRansom, http://doc.qt.digia.com/solutions/qtwinmigrate/index.html – Steed

risposta

3

Probabilmente no.

Se la GUI e la logica di business sono ben separati, allora potrebbe avere senso per spostare la gui gradualmente a Qt o implementare nuove parti in Qt - ma entrambi abbiamo conoscere la gui/logica sarà un orribile mista pasticcio insieme

Se si sta eseguendo una riscrittura (che è ciò che la Qt finirà come), allora se si tratta di una normale app di tipo business, usare C# /. Net è probabilmente più semplice.

Se le prestazioni sono critiche e hai un sacco di conoscenza di dominio legato in librerie ben definiti e separati C++ poi un front end Qt sarebbe utile

+0

Grazie, Martin. Sì, la perfomance è fondamentale e la base di codice è enorme e, sì, abbiamo una scarsa separazione logica/logica. .NET è stata la nostra prima idea, ma anche la compilazione dell'app con C++/CLI sarebbe stata un problema, per non parlare della riscrittura in C#. – Steed

0

Non fondamentalmente rispondere ad una domanda, ma potrebbe essere utile come weel . Penso che un altro modo per fare GUI con strumenti più recenti sia usare ActiveX e COM. Credo che tu possa facilmente utilizzare i componenti ActiveX nelle tue applicazioni MFC. Inoltre ci sono molti modi per creare tali controlli. Stavo usando Delphi per fare controlli che erano stati usati con successo nelle applicazioni .NET WinForms, ma per quanto ne so, tali controlli possono essere creati in ambiente .NET con poco sforzo.