Non c'è una "maniera corretta". La validità di ogni soluzione va valutata nel proprio contesto e la sua applicabilità deve tenere in considerazione le preferenze dei singoli sviluppatori. A te quale soluzione piacerebbe adottare tra le due?

A me nessuna delle due, ma è una mia opinione personale. Penso che DbContext e DbSet stiano già implementando i pattern Unit of Work e Repository e che un ulteriore livello di astrazione aggiunga poco valore. Lavorare direttamente con IQueryable è così utile e flessibile che mi sembra un peccato andare a nasconderlo dietro metodi che restituiscono IEnumerable.

Aggiungere una classe che segue il pattern Unit of Work per me ha senso quando hai più di un database o comunque più fonti dati che possono anche essere eterogenee tra loro. In questo caso (non troppo comune) i repository aiutano a nascondere i vari meccanismi di persistenza dietro una API omogenea, che semplifica il lavoro mentre sviluppi lo strato di servizi applicativi.

dalla classe UnitOfWork si accede anche ai repository.

Su questo specifico tema, la scelta può essere influenzata dal principio della interface segregation.
Il principio dice che ogni interfaccia non dovrebbe esporre più membri di quelli che vengono poi effettivamente usati da un dato componente.
Siccome è impossibile che ciascuno dei controller e servizi applicativi necessitino di TUTTI i repository esposti dallo UoW, allora qualcuno preferisce non averli affatto nello UoW. Ogni controller e servizio applicativo manifesterà la sua dipendenza dai repository che gli servono prendendoli come parametri del suo costruttore. Un container IoC gli fornirà le istanze di tali repository.

ciao,
Moreno

Ciao,

dato che hai due database, probabilmente usare il pattern UoW aggiungerà valore se gli lasci almeno gestire le transazioni.
Infatti, che succede se da un componente del tuo software usi un repository che scrive sul DB A e un altro repository che scrive nel DB B e si verifica un errore tra una scrittura e l'altra? Se vuoi che i cambiamenti vengano scritti nei due DB in maniera transazionale, la classe UoW dovrà decidere se e quando è il caso di effettuare i cambiamenti nel contesto di una transazione distribuita.

devo avere

Non "devi" fare nulla. Sei tu a dare forma all'architettura del tuo software, perché conosci meglio di tutti il problema che deve risolvere. Non seguire alla cieca gli articoli che trovi su internet perché chi li ha scritti non poteva conoscere il tuo caso specifico. Cerca di proteggerti dalla cosiddetta "programmazione cargo cult". Quando apprendi un nuovo pattern, analizza criticamente i suoi vantaggi valuta se sono sufficienti a giustificare l'incremento di complessità che introdurrà nella tua applicazione.

ciao,
Moreno