Ciao,
premetto che non c'è una soluzione ottimale per tutti gli scenari e quindi, dato che non conosco la tua applicazione, quello che scriverò di seguito potrebbe essere adatto o no al tuo caso.
Stavo pensando di creare un interfaccia al cui interno avrò i vari metodi come ad esempio add - update - delete - GetAll - FindBy etc e poi un servizio che eredita da implementa questa interfaccia per effettuare linq su T entità nel mio dbcontext.
Questi sono metodi tipici di un repository. Dato che stai usando Entity Framework, non c'è l'effettiva necessità di reimplementare questi metodi dato che te li offre già il DbContext con i suoi DbSet. Quindi, a sensazione, direi che ri-applicare una seconda volta il repository pattern per avvolgere il DbContext sia superfluo. Alcuni lo fanno lo stesso per creare uno strato di astrazione ed avere meno riferimenti possibili a Entity Framework. Per me, il valore portato da questa pratica è insufficiente a giustificarne l'esistenza nella maggior parte delle applicazioni però, ripeto, c'è chi lo fa.
In una minoranza di applicazioni, che si trovano a gestire dati da una molteplicità di fonti (es. entity framework, web service, file xml, DB2) può aver senso creare dei repository per cercare di uniformare l'interfaccia di interrogazione dei dati.
A parte questa digressione sui repository, io un servizio lo creerei per accomodare le specifiche esigenze dell'applicazione che sto scrivendo. Ad esempio, se devo realizzare un'homepage con i 10 prodotti più scontati, creerò un servizio ProductService che abbia il seguente metodo:
Task<IEnumerable<ProductDto>> GetMostDiscountedProducts(int count);
Se devo aggiornare il prezzo di un prodotto, creerò questo metodo che scatenerà, come effetto collaterale, la notifica a tutti gli utenti che l'avevano inserito nella loro lista dei desideri (delegando l'invio della notifica ad altri servizi infrastrutturali, ovviamente).
Task UpdateProductPrice(int productId, ProductPriceChangeRequest request);
Poi avrò N controller in base a quello che mi serve (controller per i clienti, controller per i prodotti) dove avrò i vari HttpGet - HttpPost etc.
Sì, ok. L'importante è non mettere logica di business nei controller. Vanno nei servizi come quello che ho appena descritto. Questo per una migliore testabilità e perché fa sempre comodo tenere la logica di business in classi che potrai riutilizzare anche in altri tipi di progetto.
ciao,
Moreno