Ho letto molto su OData con EF Core / ASP.NET Core. Mi sembra che tutti abbiano un'opinione su questo e si è un po 'confuso, quindi, a costo di sembrare stupido, ho alcune domande:
Notare che:
! NON sto parlando del classico ASP.NET 4.6 o 4.7 con EF6!
! Sto parlando di ASP.NET Core con EF Core!
Considerando le API di costruzione: ci sono cose che EF Core da solo non è in grado di gestire così come EF Core con OData?
Considerando la creazione di API - Non è meglio costruire API RESTful pulite invece di API in stile OData?
Non sta implementando la tecnologia OData sacrificando le best practice per comodità?
E a lungo termine? ASP.NET Core + EF Core non è stato creato pensando alla velocità e all'efficienza e quindi non saranno più veloci e più efficienti da soli?
Vado con il consiglio di Shawn Wildermuth che ho trovato su Pluralsight:
OData significa che le query sono sul client in modo tale che i servizi OData di versioning divengano rischiosi e sembra che la SM si stia allontanando da essa, quindi non ho fiducia nemmeno sulla redditività a lungo termine di esso.
OData su ASP.NET Core / EF Core funziona molto bene. Il versioning può essere realizzato con api versioning microsoft. Non vedo necessariamente la SM abbandonare questa tecnologia. L'API principale (grafico ms) è compatibile con odata 4.
L'uso di Odata su EF Core è davvero divertente per molti casi d'uso. Soprattutto la parte degli interrogatori mi piace molto. Per l'implementazione di scritture / comandi di solito torno a webapi / Mediatr.
Qui https://www.jannikbuschke.de/blog/cqrs-with-mediatr-and-odata/ e qui https://www.jannikbuschke.de/blog/odata-getting-started/ Ho scritto alcuni pensieri / guide su questo argomento.
Un aspetto negativo è la strumentazione e la comunità. Non c'è molto là fuori.