Un repository di facciata è un progetto OK?

Questo non è un anti-modello, e in effetti viene fatto sempre. Si chiama Service Layer.

Considera questo schema:

DB <---> Repository <---> Service Layer <---> Client
     ^       ^        ^                   ^
     SQL     EF      Objects             JSON

Quando si discute degli schemi di Fowler, è utile avere una copia effettiva di il suo libro . È particolarmente utile se intendi essere "compatibile con Fowler".

Repository

Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.

Il repository espone un'interfaccia semplice, in genere CRUD con forse alcune funzionalità di criteri come

criteria.Equals(Person.LastName, "Fowler");

Il livello di servizio, al contrario, espone le operazioni commerciali.

Service Layer

Defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation.

È questo livello di servizio in cui risiede la tua logica di prendere un repository di indirizzi e un repository di clienti, la dipendenza da iniettare e aggiornare tutto in un unico posto.

Naturalmente, se hai solo bisogno di una sorta di classe di supporto che avvolge le tue funzionalità in un unico pacchetto, puoi farlo anche tu.

Ulteriori letture
P di EAA: repository
P di EAA: Service Layer

Questo non è intrinsecamente problematico.

O meglio, non la vedo come una violazione del schema del repository . Il punto del pattern è di nascondere un meccanismo di memorizzazione potenzialmente complesso o sconosciuto. Quindi, al contrario di esso è un anti-pattern, il pattern del repository è di valore particolare proprio nella tua situazione, quando un oggetto business (o un concetto) non mappa in modo naturale o perfetto per un solo tavolo.

Per dirci un nome, penso che hai a che fare con ciò che DDD chiamerebbe un Aggregato .

Aggregates are the basic element of transfer of data storage - you request to load or save whole aggregates. Transactions should not cross aggregate boundaries.

L'enfasi è mia.

Se hai un concetto di dominio che copre o "aggrega" altri oggetti business / dominio, avere un singolo punto di invocazione per i salvataggi e così via è buono , perché può nascondere i dettagli cruenti e creare transazioni secondo necessità.

Se la tua definizione di entità ha mappato alle tue tabelle in modo naturale su base uno a uno, potrei effettivamente suggerire che il pattern del repository è eccessivo. Il schema di registrazione attivo è di solito più semplice e meno codice da implementare! E, se la memoria serve, Martin Fowler suggerisce nel suo libro dei modelli che il pattern Active Record è una buona scelta per " semplici "mappe di schemi di entità". È quando ti complichi che inizi davvero ad aver bisogno di un'astrazione più sofisticata, come un repository.