Come condivido le classi comuni tra i moduli di Windows e le applicazioni Web utilizzando C #?

Question

Come condivido le classi comuni tra i moduli di Windows e le applicazioni Web utilizzando C #?

#1 da (3 voti)
#2 da (1 voti)

0

Nel nostro ambiente abbiamo più server ERP più dati provenienti da più fonti. Ho bisogno di creare una roadmap di sviluppo per i prossimi anni in quanto è ovvio che le applicazioni secondarie saranno necessarie per molte cose.

La scelta è che lo sviluppo si verificherà con le tecnologie Microsoft. Ciò significa che svilupperò applicazioni Web (MVC, moduli Web e.t.c) o applicazioni standard di Windows Form.

La cosa qui è che creerò delle classi che incapsuleranno la logica del business che voglio applicare ai diversi progetti.

Cosa ho pensato finora:

1) Crea librerie di librerie dll contenenti la logica richiesta

2) Riutilizzare queste librerie nelle mie app.

Ma per quanto riguarda le app Web? Devo utilizzare le DLL direttamente o dovrei incapsularle nei servizi Web e utilizzare i servizi Web nelle app Web? In generale mi piacerebbe scoprire come dovrei costruire la mia strategia.

development-process strategy

posta earthdog 04.04.2012 - 17:05

fonte

2 risposte

Leggi altre domande sui tag development-process strategy

Raccomandazione per un database di interrogare i record con attributi che sono matrici o hash? Perché avere un'applicazione con GUI su linux quando è disponibile la riga di comando?

score 3 · Answer 1

But what about the web apps? Should i use the dlls directly or i should encapsulate them in web services and consume the web services in web apps?

Finisce davvero a seconda di quanto sarà necessario ridimensionare.

Direi che dovresti iniziare semplicemente riutilizzando direttamente le librerie nelle tue applicazioni web. Questo ha il minor costo in termini di velocità di sviluppo, semplicità e basso sovraccarico di IO (parlando del traffico di rete), oltre al vantaggio di eseguire in-process.

L'utilizzo di servizi Web è una proposta costosa (hardware aggiuntivo, costi di manutenzione, livello software aggiuntivo, spese generali di I / O ecc.) e sarà più lento di andare in-proc.

score 1 · Answer 2

Questo suona come lo scenario ideale per un'architettura orientata ai servizi che utilizza servizi web.

Incapsula ogni unità discreta di conoscenza aziendale, funzionalità che possono essere condivise tra uno o più servizi e consenti ad altre app di usarli.

Questa centralizzazione delle funzionalità significa che tutte le app possono essere aggiornate se la funzionalità aziendale centrale cambia in qualche modo.

Se è necessario apportare alcune modifiche all'interfaccia, è necessario essere consapevoli del fatto che tutte le app che consumano saranno interessate, ma ci sono modi per aggirarle con il controllo delle versioni ecc.