Utilizzando VCL per il web (intraweb) come un trucco per l'aggiunta di un'interfaccia web per un lascito non a più livelli (2 livelli) applicazione Win32 Delphi ha senso?

StackOverflow https://stackoverflow.com/questions/2811748

Domanda

La mia squadra sta mantenendo una grande applicazione Client Server Win32 Delphi. Si tratta di un client / applicazione server (client di spessore) che utilizza componenti Devart (SDAC) per connettersi a SQL Server.

La logica di business è spesso "intrappolato" in gestori di eventi del componente, in ogni caso con un certo grado di refactoring è fattibile per spostare la logica di business in unità comuni (una grande parte di questo lavoro è già stato fatto durante il refactoring ... mantenendo applicazioni legacy qualcun altro ha scritto è molto frustrante, ma questo è un lavoro molto comune).

Ora c'è la richiesta di un'interfaccia web, ho diverse opzioni, naturalmente, in questa domanda che voglio mettere a fuoco il VCL per l'opzione web (IntraWeb).

L'idea è quella di utilizzare il codice comune (gli stessi file PAS) sia per l'/ applicazioni client server e l'applicazione web. Ho sentito di molte persone che le applicazioni legacy spostati da Delphi per intraweb, ma qui sto cercando di mantenere il cliente Spesso troppo.

L'idea è quella di utilizzare codice comune, può essere con alcune direttive del compilatore di scrivere codice specifico: 

{$IFDEF CLIENTSERVER}
  {here goes the thick client specific code}
{$ELSE}
  {here goes the Intraweb specific code}
{$ENDIF}

Poi un altro problema è il "piano di migrazione", diciamo che avere 300 caratteristiche e la prima release avrò solo 50 di loro disponibili nell'applicazione web. Come tenere traccia di esso? Stavo pensando di (ab) tramite interfacce Delphi per gestire questa situazione. Ad esempio per l'autenticazione utente riuscivo a muovere tutto il relativo codice in una procedura e dichiarare un'interfaccia simile: 

type
  IUserAuthentication= interface['{0D57624C-CDDE-458B-A36C-436AE465B477}']
    procedure UserAuthentication;
  end;

In questo modo, come ho implementare l'interfaccia IUserAuthentication in entrambe le applicazioni (spessore Client e Intraweb) so che Tale caratteristica è stato "portato" per il web. In ogni caso non so se questo approccio ha senso. Ho fatto un prototipo per simulare l'intero processo. Si lavora per un'applicazione "Ciao mondo", ma mi chiedo se ha senso su una grande applicazione o questa idea interfaccia è solo controproducente e può ritorcersi contro.

La mia domanda è: fa questo approccio ha senso? (L'idea interfaccia è solo un'idea in più, ma non è così importante come la parte di codice comune descritto sopra) è una valida opzione?

ho capito dipende molto del tipo di applicazione, in ogni caso ad essere generico il mio uno è nella / dominio contabile CRM, e il numero di utenti simultanei su una singola installazione è in genere inferiore a 20 con punte di 50.

COMMENTO EXTRA (UPDATE): pongo questa domanda perché da quando non ho un'applicazione n-tier vedo Intraweb come l'opzione unica per avere un'applicazione web che ha codice comune con il client di spessore. Lo sviluppo di webservices dal codice Delphi non ha senso nel mio caso specifico, quindi l'alternativa che ho è quello di scrivere l'interfaccia web utilizzando ASP.NET (duplicare la logica di business), ma in questo caso non riesco a sfruttare il codice comune in un modo semplice. Sì ho potuto usare le DLL forse, ma il mio codice non è adatto per questo.

È stato utile?

Soluzione

La cosa più importante che dovete ricordare è questa:

  • Il tuo spessore cliente processo .EXE è utilizzato da una sola persona alla volta (più persone avranno più istanze di tale .EXE).
  • Il vostro processo .EXE intraweb sarà utilizzato da molte persone alla volta. Tutti condividono la stessa istanza del processo.

Ciò significa che la logica di business non deve essere riscritta solo in unità comuni, le istanze della logica di business devono essere in grado di risiedere in memoria più volte, e non interferire.

Si inizia con la logica di business che parla al database:. Devi essere in grado di avere più connessioni al database, allo stesso tempo (in pratica un pool di connessioni al database funziona meglio)

Nella mia esperienza, quando si può refactoring la logica di business in datamodules, avete un buon punto di partenza per supportare sia un Intraweb e una versione thick client della vostra app.

Non si deve dimenticare l'interfaccia utente:

  • thick client sostenere forme modali, e hanno una molto più ricca interfaccia utente
  • Web browser supporta solo le finestre di dialogo di messaggi (e poi: quelli sono molto limitati), tutta roba di fantasia UI costa un sacco di tempo di sviluppo (anche se, per esempio, TMS ha una certa belle componenti per Intraweb )

Quindi, per concludere, si deve far fronte con la natura stateless del protocollo HTTP. Per ovviare a questo, è necessario sessioni. Intraweb si prenderà cura della maggior parte della parte della sessione.
Ma è necessario porsi domande come queste:

  • quello che dovrebbe accadere se un utente è inattivo per XX minuti?
  • quanto lo stato della sessione posso archiviare nella memoria? e che cosa se non va bene?
  • cosa devo fare con lo stato di sessione che non rientra nella memoria?

Questo è solo l'inizio, quindi cerchiamo uso sapere quando avete bisogno di più informazioni.
Se diventa molto specifico per la vostra applicazione, si può sempre contattarmi direttamente:. Solo a me google

- Jeroen

Altri suggerimenti

Credo che se si sposta l'applicazione per n-tiers sarà una soluzione migliore, sarà più facile dopo che per essere utilizzati dalle applicazioni desktop e web.

hai già fatto la prima parte disaccoppiando la logica di business dalla presentazione, è possibile utilizzare RemObject SDK o DataSnap che in bundle con Delphi.

Dopo che avrete a lavorare applicazione desktop, ed è possibile utilizzare Intrawebm Asp.net o che cosa mai per la parte Web, e in questo modo non sarà necessario duplicare di nuovo la logica di business per la parte web.

di solito la conversione applicazione desktop al web non è facile come si pensava, perché lavorano in ambiente diverso, ed è necessario per costruire ciascuno in quanto di natura.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top