Ristrutturazione di interfacce simili a un progetto unificato

Nel mio progetto, ho diversi tipi di controller API Web (e relativi servizi e repository). Quando ho iniziato, ho creato un'interfaccia di tipo generico che descriveva le funzionalità di base che ogni controller / servizio / repository dovrebbe avere.

Da allora, ci sono stati nuovi tipi di entità che questi controller devono gestire. Ad esempio, prima, dovevamo gestire solo un'entità di base con un ID int32 e diversi altri campi. Ora, dobbiamo gestire le entità figlio e le entità con una stringa anziché con l'ID int32.

Ho risolto questo problema creando queste interfacce:

interface IService<T>
{
    List<T> GetAll();
    T Get(long id);
    // ...
}

interface IChildService<T>
{
    List<T> GetAll(long id);
    T Get(long id);
    // ...
}

interface IStrService<T>
{
    List<T> GetAll();
    T Get(string id);
    // ...
}

interface IChildStrService<T>
{
    List<T> GetAll(string id);
    T Get(string id);
    // ...
}

Funziona, ma odio tutto a riguardo. Voglio poter fare riferimento a un servizio dichiarando IService<ObjType> , non utilizzare IStrService qui e IChildService lì.

C'è un modo per ridisegnare ciò per essere più generico, astratto e supportare la mia situazione attuale? Ho riflettuto sulla possibilità di astrarre il mio tipo di ID, in modo che non abbia importanza di cosa sia - una stringa o un int, o qualunque cosa succeda in futuro. Non sono sicuro di come gestire ChildServices, dato che hanno bisogno dell'ID del genitore per restituire un elenco di risultati.

Devo anche menzionare che, nella primissima implementazione, abbiamo usato questo:

interface IService<T>
{
    List<T> GetAll();
    List<T> GetAll(long parentId);
    List<T> GetAll(string parentId);
    // ...
}

Ma come puoi immaginare, questo è diventato molto disordinato, e penso che superi lo scopo delle interfacce se dovessi solo definire il 50% dei metodi con una NotImplementedException.