Servizi Web vs funzioni locali

Implementerei tutta la logica in una libreria separata (chiamiamola api.dll) non associata a nessun trasporto, quindi potresti usarla dove vuoi. Voglio dire, se crei una web API tramite http, ci saranno alcuni controller che chiamano i metodi api.dll per servire le risposte. Ma puoi anche fare riferimento a api.dll dalla tua app desktop e usarlo direttamente senza dover effettuare richieste HTTP sulla web API (più lento e complicato). E domani, se decidi di cambiare il trasporto dei servizi web da http a websockets, non c'è molto lavoro da fare se non chiamare i metodi api.dll dal websocket. Non avrai problemi di concorrenza. Usa la programmazione asincrona ogni volta che puoi, inclusi i controller. In questo modo servirai più richieste con lo stesso numero di thread. Per quanto riguarda l'OData, è una questione di gusti. Personalmente non mi piace. Sembra una soluzione di scatola magica, finisci senza un'API ben definita. Ma ancora, dipende dal caso d'uso.

EDIT: non posso commentare la risposta di @RubberDuck quindi risponderò qui: L'idea è di non implementare nulla nei controller tranne la chiamata alla libreria condivisa. L'unica fonte di verità è la libreria condivisa.

Se hai bisogno di esporre un servizio web per uno dei tuoi clienti, allora tutti i client devono accedere ai dati attraverso il servizio web. Vorrete un punto di accesso singolo ai vostri dati. In caso contrario, nel tuo controller del servizio web avrai inevitabilmente alcune importanti logiche di business che non vengono propagate a tutti i client di data.dll o, peggio, ci sono un sacco di clienti che lavorano attorno allo stesso problema in modi inconsistenti.

L'intero punto di un servizio web è quello di separare il client dal database e facilmente essere in grado di accedervi facilmente tramite un'unica fonte di verità. Andare in giro per il tuo servizio per alcuni clienti, ma non per altri, alla fine causerà a qualcuno un mal di testa abbastanza grande.