Esposizione della business logic come servizio WCF

4

Sto lavorando a un progetto di livello intermedio che incapsula la logica aziendale (utilizza un livello DAL e serve un server di applicazioni Web [ASP.net]) di un prodotto distribuito in una LAN. Il BL funge da gruppo di servizi e oggetti dati che vengono richiamati in seguito all'azione dell'utente.

Al momento attuale, il DAL funge da applicazione separata mentre BL lo utilizza, ma viene utilizzato dall'applicazione Web come DLL . Sia DAL che l'applicazione Web vengono distribuiti su server diversi all'interno dell'organizzazione e poiché la DLL BL viene utilizzata dall'applicazione Web, risiede nello stesso server.

La cosa peggiore nell'esporre BL come DLL è che abbiamo perso la cognizione di ciò che esponiamo. La distribuzione non è un problema così grande dal momento che, per lo più, le versioni dei prodotti vengono distribuite insieme.

Consiglieresti di migrare dalla DLL al servizio WCF? Se è così, perché? Conosci qualcuno che ha avuto un'esperienza simile?

    
posta Oren Schwartz 27.11.2011 - 01:01
fonte

3 risposte

1

La domanda principale da porsi è Perché dovrei (come in che cosa guadagnerei) aggiungendo WCF al mio progetto. Si otterrebbe scalabilità, ma al costo di aumentare la complessità. Hai bisogno di scalabilità? La flessibilità nelle distribuzioni (i diversi livelli possono essere più facilmente su diversi piani di sviluppo) è un altro vantaggio, ma hai menzionato che era una priorità bassa.

Attualmente sto lavorando in un ambiente con C # WebParts che colpisce i servizi Web Java, abbiamo combattuto su versioni, accoppiamento stretto e allentato, API e altro, ma ci concentriamo sempre sul ROI. Quanto questa architettura cambierà nel corso del ciclo di vita del progetto, rispetto a quanto risparmiamo nei costi di manutenzione e sviluppo.

Direi di farlo. È possibile aggiungere il servizio WCF sullo stesso computer che esegue attualmente il Web. Ritengo che la separazione delle preoccupazioni, la flessibilità e la scalabilità varrebbe la pena, poiché il cambiamento dovrebbe essere minimamente invasivo.

    
risposta data 27.11.2011 - 03:34
fonte
3

La mia raccomandazione sarebbe quella di spostare la logica aziendale sullo stesso server che ha il livello di accesso ai dati, quindi esposto la logica di business come servizi web usando WCF. L'interfaccia utente Web utilizzerà quindi la logica aziendale interagendo con i servizi.

Quindi la mia risposta è sì alla tua domanda, ti consiglierei di migrare dalla DLL al servizio WCF.

In un certo senso puoi guardare l'applicazione web come livello di presentazione. Il livello di presentazione e la logica di business sono due livelli diversi. Naturalmente è possibile distribuire entrambi sullo stesso host. Tuttavia, nella maggior parte dei casi è meglio implementare la logica aziendale e l'accesso ai dati sullo stesso host.

Vorrei fare ancora un passo avanti e raccomandare di valutare se è necessario esporre il livello di accesso ai dati (DAL) tramite i servizi. Se non lo fai, la combinazione del livello di accesso ai dati e della logica aziendale in un insieme di servizi può essere utile.

Concettualmente un servizio incapsula i suoi dati e quindi l'accesso ai dati sarebbe un dettaglio interno di un particolare servizio. Allo stesso modo un servizio offre pezzi di logica aziendale. Pertanto, la creazione di sezioni verticali di funzionalità che coprono sia la logica aziendale sia l'accesso ai dati per ogni sezione in un servizio separato spesso offre un buon livello di granularità e modularizzazione.

Ovviamente potresti avere fattori aggiuntivi che possono influenzare le tue scelte.

    
risposta data 27.11.2011 - 01:54
fonte
0

Ho lavorato su molti progetti con logica aziendale e livelli Web separati. Alcuni sono stati suddivisi in servizi WCF, alcuni sono stati utilizzati come DLL.

Il modo in cui preferisco usare le librerie interne condivise è includere il progetto di librerie (comuni) condivise nelle soluzioni in cui è usato.

  • Soluzione WebApp
    • Progetto commerciale
    • Progetto Web

Quindi ho visibilità immediata in quel progetto. Devi assicurarti che il tuo team comprenda che la modifica del progetto commerciale avrà ripercussioni su altri prodotti, ma il più delle volte non ho riscontrato problemi.

L'esposizione di una libreria condivisa come servizio WCF (o WebAPI) da utilizzare internamente aggiunge un po 'di complessità e dalla mia esperienza dovrebbe essere fatta solo quando c'è un vantaggio significativo a farlo.

Se hai un'elaborazione intensiva della cpu, questa è un'ottima ragione per usare i servizi web. puoi scalare l'hardware o aggiungere altri server quando necessario, e se il tuo server di servizio si blocca, non rimuove l'host web.

Se è necessario esporre i dati a una terza parte, tuttavia utilizzerò una libreria condivisa all'interno di un'applicazione WCF o WebAPI e esporrò solo ciò di cui ha bisogno la terza parte.

  • Soluzione di servizio esposta pubblicamente
    • Progetto commerciale
    • Progetto di servizio pubblico (espone solo dati limitati, sicurezza estesa)

Ho sentito che puoi separare il livello dati dal livello della tua app Web utilizzando i servizi per la sicurezza, ma non l'ho mai provato in questo caso.

    
risposta data 19.09.2016 - 20:56
fonte

Leggi altre domande sui tag