Ho un grande progetto WebApi con alcune dozzine di controller. Ogni controller rappresenta un prefisso endpoint, proprio come farebbe un normale progetto MVC. Ad esempio:
CarsController.cs rappresenta http://api.example.com/api/Cars
Nell'esempio precedente, il primo ruolo di quel controller è di fornire azioni CRUD per l'entità Car . A mano a mano che l'applicazione è cresciuta, scopriamo che per un'auto con un dato ID, potremmo voler operare su AccidentHistory come tale:
http://api.example.com/api/Cars/77/AccidentHistory
Ora, questo endpoint funge da azioni CRUD per la cronologia degli incidenti di auto con ID 77. Può andare avanti per qualsiasi numero arbitrario di livelli. La gerarchia degli endpoint REST è ottima, tutti la amano. Ma questo pone un problema nel mondo del routing basato su MVC. Ci piace avere un [Entity]Controller.cs per ogni entità di primo livello. Ogni entità discendente deve quindi risiedere nel file del controllore del più grande antenato. Finora, abbiamo assegnato a ciascuna entità discendente il proprio #Region in Visual Studio, ma non sembra una buona soluzione.
La mia prima idea era quella di spostare le azioni di ciascuna sub-entità in una classe parziale. Ad esempio:
CarsController.AccidentHistory.cs conterrà le azioni per l'endpoint dell'esempio precedente.
Questa sembra una buona idea, ma ci sono molte persone nella comunità che credono che l'uso di classi parziali sia un enorme odore di codice, e sono pronti a sottolineare che i partial sono stati implementati come un work-around per classi WinForms che erano generato automaticamente, ma deve essere modificato dallo sviluppatore.
Un altro chiodo nella bara della classe parziale, almeno per me, è che stiamo usando CodeDom per generare metodi TypeScript per ogni endpoint di primo livello, quindi c'è una classe in TypeScript che può essere usata per accedere a tutte le azioni per un dato endpoint. Con l'approccio di classe parziale, ci sono grossi problemi nel far sì che la generazione faccia ciò che vogliamo. (Visto che tutti i partial appaiono come la loro piena implementazione, si ottengono definizioni di classi duplicate generate in più file.
Quindi, c'è un modo migliore per organizzare il codice del controller per le rotte API RESTful in WebApi? Uno in cui possiamo sapere rapidamente dove si basa il codice per un determinato endpoint semplicemente su URL e metodo? Senza avere un controller per entità? Pensieri?