Chiamare Web API vs aggiungere riferimenti alle DLL sottostanti [chiuso]

4

Questa è più una questione di architettura, e voglio sapere tutti i possibili pro e contro dell'approccio.

Nella mia organizzazione, abbiamo un'applicazione ASP.NET che dice "A", un progetto API Web che dice "W", e le DLL sottostanti dicono "D" che chiama "E" che è fisicamente su un altro server.

Per la maggior parte delle cose (in SPA), stiamo facendo una chiamata ajax da A a W per accedere alla funzionalità sottostante che si trova in D.

A e W sono entrambi distribuiti e ospitati sullo stesso server Web di diverse applicazioni e W ha riferimento a D così D è distribuito con W.

Per una delle funzionalità, è necessario eseguire l'elaborazione lato server sul codice della pagina ASPX.

Sto suggerendo al mio team di continuare a chiamare da A a W usando il client http e mantenere un accoppiamento lento tra l'applicazione A e le DLL d, ma molti (direi tutti gli altri membri del mio team) sono favorevoli di aggiungere il riferimento di D a A, quindi ora D verrà distribuito con A a fianco.

Il mio suggerimento non è così valido che abbiamo facilitato l'implementazione che avremmo ottenuto aggiungendo il riferimento diretto per D in A? Fammi sapere se non sono abbastanza esplicativo.

    
posta Guanxi 17.11.2014 - 16:35
fonte

3 risposte

1

L'utilizzo di un'API Web consente di programmare su un'interfaccia anziché un'implementazione concreta.

Necessità di generare una fattura (ad esempio)? Basta chiamare il metodo API Web per generare quella fattura. Se in futuro dovesse sorgere il bisogno di cambiare il modo in cui funziona la fatturazione, puoi semplicemente cambiare il codice dietro l'interfaccia, (o scambiarlo per un esercizio di fatturazione completamente diverso tutti insieme).

Accoppiare strettamente il front-end a una DLL introduce una dipendenza in cui non è necessario che esista. Ciò si traduce in un elevato costo di manutenzione quando i requisiti cambiano in quanto è necessario aggiornare sia l'applicazione che la DLL. L'utilizzo di un'API Web consente di modificare la logica di business dell'applicazione senza dover ridefinire l'applicazione front-end.

    
risposta data 05.03.2015 - 13:11
fonte
1

Sembra che ci sia poca differenza in termini di accoppiamento. Se stai codificando direttamente con WebAPI, sei dipendente dalle sue interfacce. Se esegui il codice direttamente contro la DLL, sei dipendente dalle sue interfacce.

Rendi la distinzione irrilevante. La tua applicazione non dovrebbe idealmente sapere o preoccuparsi se alla fine si basa su un servizio web, un servizio locale o una biblioteca locale o persino quale linguaggio o tecnologia sono alla base la funzionalità è costruita su Scegli il tuo tipo preferito di wrapper e davvero disaccoppia l'applicazione da entrambi l'API e la DLL. Puoi costruire (o estendere) wrapper per entrambi e testare entrambi per prestazioni, manutenibilità, ecc.

    
risposta data 05.03.2015 - 17:06
fonte
1

Da Martin Fowler

My First Law of Distributed Object Design: Don't distribute your objects

Perché scegliere di sostenere il sovraccarico e l'instabilità di un servizio Web se la logica di business desiderata si trova in una DLL? Fai riferimento alla DLL e mantieni tutti i metodi come locali, scattanti e stabili.

Se stavi creando il tuo sito web in un linguaggio non .NET, allora hai un buon caso per usare un servizio web, ma non è questo il caso.

Anche se non hai avuto accesso alla base del codice DLL, puoi gestire un server dei pacchetti Nuget interno e utilizzare Nuget per gestire tale dipendenza.

Se il servizio web ha una logica di business aggiuntiva di cui hai bisogno, allora usalo. In caso contrario, utilizzare la DLL.

    
risposta data 05.03.2015 - 19:46
fonte