Nell'architettura SOA, con molti servizi che implementano la persistenza dei dati e la logica di base, c'è anche un posto per le stringhe di connessione nelle applicazioni client Desktop? O tutto dovrebbe passare attraverso il servizio?
Cambia per Microservices?
Nella mia esperienza, le stringhe di connessione sono richieste solo nei livelli che si connettono direttamente al database. Da un punto di vista SOLID, le stringhe di connessione dovrebbero essere in qualche modo particolarmente specifiche per la connessione al database, forse una proprietà su un'implementazione IDatabaseConnection, caricata da un file di configurazione per facilitare il passaggio.
Tuttavia, è perfettamente consentito avere più servizi e anche il passaggio di parametri ai metodi su tali servizi è perfettamente consentito. Quindi, passare un valore per cui il database a cui connettersi va bene (se è un po 'sporco), ma almeno farei un'ulteriore astrazione della stringa di connessione, per esempio solo il suo nome piuttosto che la stringa completa.
Un'altra architettura potrebbe essere quella di avere due servizi dati dedicati al recupero dei dati da ciascuno dei database e un altro servizio per servire i client con tali dati nel formato che si aspettano.
Per quanto riguarda i microservizi, gli stessi principi, a parte i servizi, sono ulteriormente separati.
Lo considero anche un rischio per la sicurezza di includere stringhe di connessione su qualsiasi client, ha nomi di macchine, password, nomi utente, tutti i tipi lì dentro.
Leggi altre domande sui tag architecture microservices web-services soa enterprise-architecture