Per un po 'di tempo, il mio team e io abbiamo avvolto il nostro livello di accesso ai dati in una facciata del servizio Web (utilizzando WCF) e chiamandolo dal livello della logica aziendale . Nel frattempo, potremmo semplicemente utilizzare il modello di repository in cui il livello della logica aziendale consuma il livello di accesso ai dati localmente attraverso un'interfaccia e, in qualsiasi momento, possiamo cambiare le cose in modo che colpiscano un servizio (se necessario).In Wrap o Not to Wrap: avvolgimento dell'accesso ai dati in una facciata di servizio
La domanda è: quando è il momento giusto per avvolgere il livello di accesso ai dati in una facciata di servizio e quando no? In questo momento, sembra che il vantaggio principale sia che altre applicazioni possono consumare il servizio, ma se sono applicazioni interne scritte in .NET, possono invece semplicemente utilizzare l'assembly .NET. Esistono altri vantaggi nell'avere il DAL racchiuso in un servizio di cui non sono a conoscenza?
Anche per un'app interna, il consumo diretto dell'assembly .NET potrebbe essere un PITA da aggiornare se si dispone di molti utenti dell'assembly, ma un servizio Web sarebbe molto più snello. – Nate
Questa è una grande domanda ... La spesa relativa alla serializzazione/trasporto/deserializzazione può essere molto costosa, quindi ha senso considerare altri modelli. Il rovescio della medaglia, avere una facciata di servizi può rendere più facile arricchire e trasformare i dati. Un altro aspetto interessante di questo modello è la possibilità di integrare endpoint in coda per esigenze di archiviazione ignifughe. – JoeGeeky