Ciao,

Se il server (su cui stà SQL Server) è posizionato in una sottorete diversa da quella degli utenti, cosa cambierebbe a livello architetturale e di stringa di connessione?

Nella connection string non cambia nulla, l'importante è che il router/firewall sia stato configurato per indirizzare il traffico verso il database server quando si richiede il suo IP dall'altra subnet. Consultati con l'amministratore di rete della tua azienda (o comunque con quello dell'azienda presso la quale installerai il software).

in VPN e Desktop Remoto non dovrebbe cambiare niente

No, non cambia nulla. Nel caso della VPN, il database server continuerà ad essere raggiungibile come se il PC client fosse fisicamente connesso alla rete locale. Nel caso del desktop remoto è proprio tutto uguale dato che stai controllando una macchina che è fisicamente connessa alla rete locale e sulla quale sta girando l'applicazione desktop.

ma in caso non fosse possibile l'utilizzo di VPN o Desktop Remoto continua ad essere un'applicazione desktop

Certo, continua ad essere un'applicazione desktop. A meno che tu non voglia esporre la tua istanza di Sql Server su internet (cosa da non fare, ma chiedi lumi al tuo amministratore di rete o al DBA) allora dovrai predisporre un webservice.
Il backend dell'applicazione, a questo punto, diventerà il webservice e non più il database SQL.

Io preferisco sempre usare un webservice perché collegarmi direttamente al database è una soluzione molto cruda che consente ad un utente di avere il pieno controllo sui dati. Basta usare la connection string in Sql Server Management Studio per bypassare qualsivoglia logica tu abbia inserito nell'applicazione desktop.

Usando un webservice, invece, puoi inserire uno strato di autenticazione, autorizzazione e logica di business che il client non può bypassare.
Per le applicazioni desktop orientate ai dati a volte uso un WCF Data Service ma anche una Web API con OData fa il suo egregio lavoro.

ciao,
Moreno

---

Modificato da BrightSoul il 25 gennaio 2017 20.49 -

Ciao,

si potrebbe usare .net Core

Sì ma... ancora no :) Tutto dipende dal quando questa issue verrà chiusa: riguarda il supporto ad OData per ASP.NET Core, che ancora non c'è.
https://github.com/OData/WebApi/issues/772

Nel tuo caso, secondo me, usare un webservice che supporti la sintassi di interrogazione di OData ti semplificherà molto lo sviluppo. Infatti, da un'applicazione desktop (ma anche da un'applicazione web) è normale che l'utente voglia cercare su vari campi, ordinare i risultati, paginarli, e così via.
Scrivere codice per supportare tutte queste funzionalità è certamente possibile, ma devi farlo a mano quando invece un WCF Data Service o ASP.NET Web API già lo fanno.

oppure anche MVC (anche se alcuni sostengono che MVC non nasce come web service)

Hanno ragione, perché ASP.NET MVC è una tecnologia creata per la parte UI di un sito web. MVC può certamente buttare fuori del JSON ma ti trovi in difficoltà quando invece è il client che ti manda del JSON.

Da ciò che hai scritto nel post mi sembra che ASP.NET Web API con il supporto ad OData sia la soluzione che potresti gradire di più. Un domani potrai portare il codice su ASP.NET Core, se lo desideri. Metti il più possibile della logica di business in class libraries per il .NET Standard, in modo che le potrai portare tali e quali su ASP.NET Core.

La scelta di un web service piuttosto che un altro dipende anche dai client (desktop, mobile)?

Sì, le REST API come quelle di ASP.NET Web API sono più facili da consumare, e quindi sono adatte anche per client molto semplici come i dispositivi IoT o applicazioni javascript, oppure in generale per applicazioni orientate ai dati.

Se il "client" invece è un'altra applicazione .NET (come nel tuo caso), allora puoi anche scegliere WCF a cuor leggerlo perché Visual Studio ti crea delle classi proxy che astraggono dalla complessità sottostante e ti ritrovi con funzionalità avanzate tipo transazioni, sessioni, comunicazione duplex e così via. Inoltre il protocollo usato può essere binario, il ché ottimizza la trasmissione dei dati. Questo è il motivo per cui ti ho parlato del WCF Data Service, che pure supporta OData.

A livello pratico ci sono vantaggi/svantaggi nell'utilizzarne uno piuttosto che un altro?

Un webservice ASP.NET Web API non ha le stesse funzionalità di WCF. Dipende da cosa ti serve fare.
La scelta spetta a te, penso. Magari fai delle prove con le varie tecnologie per capire cosa funziona meglio nel tuo caso.

ciao,
Moreno