![\"\"](\"http:\/\/blogs.encamina.com\/desarrollandosobresharepoint\/wp-content\/uploads\/sites\/8\/2020\/07\/odata.jpg\")
<\/p>\n<\/p>\n
A la hora de hacer las consultas sobre nuestras WebApi, OData es un est\u00e1ndar propio de Microsoft<\/strong> que est\u00e1n adoptando la mayor\u00eda de API\u2019s de los productos punteros para establecer su comunicaci\u00f3n con el Front. Apps como Twitter, Facebook y naturalmente Microsoft Graph, utilizan esta forma de realizar consultas a sus objetos de negocio. Como desarrolladores, muchas veces no ponemos OData por miedo al performance que ocasiona en el Backend. \u00bfC\u00f3mo lo podemos solucionar? En este art\u00edculo vemos c\u00f3mo cuidar las consultas para evitar matar muchos gatitos y ahorrarnos esfuerzos en el desarrollo \ud83d\ude05<\/p>\n Este art\u00edculo es una continuaci\u00f3n del\u00a0post<\/a>\u00a0que escribi\u00f3 mi compa\u00f1ero\u00a0Sergio Parra<\/a>. As\u00ed que si no hab\u00e9is o\u00eddo nada sobre OData y c\u00f3mo empezar a utilizarlo en los desarrollos en .NET, leedlo y luego continuad por este punto \ud83d\ude42<\/p>\n Una vez nos hemos le\u00eddo el art\u00edculo anterior, ya sabemos lo qu\u00e9 es OData: un est\u00e1ndar que define un conjunto de buenas pr\u00e1cticas para la construcci\u00f3n y consumo de RESTFul API.<\/p>\n De todo lo que tiene Odata, centr\u00e9monos en la parte relacionada con la realizaci\u00f3n de consultas<\/strong>. A ver, levantad la mano: \u00bfen cu\u00e1ntos proyectos, en las llamadas para hacer filtros creas un objeto para indicar sobre qu\u00e9 campo o valores filtramos?\u2026 No me digas que es una tarea sencilla hacer eso. Pero ojo, \u00bfa cu\u00e1ntos nos ha pasado que, una vez instalado, surge un nuevo requerimiento y no podemos filtrar por este u otro campo? Eso, a nivel de desarrollo implica que tenemos que hacer una modificaci\u00f3n en la API y posteriormente modificar la consulta, DTO\u2019s, Test (si los hubiera). Es decir, una simple modificaci\u00f3n, implica dedicar un tiempo extra muy valioso.<\/p>\n Otra de las ventajas que tiene OData respecto a nuestro desarrollo \u201cCustom\u201d es que es un est\u00e1ndar. Esto hace que cualquier developer<\/strong> (ya sea de Front\/Back) pueda entender c\u00f3mo funciona<\/strong> y pueda realizar las peticiones a la API que necesita en su desarrollo.<\/p>\n Ahora bien, este \u00faltimo punto tambi\u00e9n puede ser un inconveniente dependiendo de la madurez del equipo de desarrollo.<\/p>\n Pensad un supuesto en el que\u00a0 se cree un \u00fanico controlador con OData y se permita realizar cualquier filtro y consulta sobre dicha entidad. Esto puede hacer que para establecer determinada l\u00f3gica de negocio, en lugar de implementar un m\u00e9todo en el controlador con dicha l\u00f3gica, se indique que esta l\u00f3gica se haga implementando filtros con OData. Para m\u00ed, este supuesto es un mal uso de OData. S\u00ed,\u00a0 hemos dicho que nos ahorra tiempo de implementaci\u00f3n, pero esto no implica que en cada entidad tengamos que indicar sobre qu\u00e9 campos queremos filtrar y sobre todo,\u00a0 qu\u00e9 queremos mostrar.<\/p>\n Imaginad un caso en el que tengamos una lista de clientes y un filtro en el que mostremos cualquier informaci\u00f3n sobre \u00e9l. Por ejemplo, informaci\u00f3n tan sustancial como el importe que nos adeuda\u2026 No creo que la mejor opci\u00f3n sea que implementemos OData y con ella poder permitir cualquier opci\u00f3n.<\/p>\n Vamos a partir de que tenemos una API de Avengers. En primer lugar vamos a configurar e instalar los paquetes Nuget<\/strong> necesarios para empezar a utilizar OData en nuestra API. En este caso nos har\u00e1 falta el siguiente paquete:<\/p>\n Una vez esta instalado, tocaremos el StartUp<\/strong> para a\u00f1adirle el soporte para OData. <\/strong>Para ello, en el m\u00e9todo Configure Services le indicamos que vamos a hacer uso de OData y a\u00f1adimos la siguientes l\u00edneas:<\/p>\n Ahora, dentro del m\u00e9todo Configure del mismo StartUp, substitu\u00edmos app.UseRouting() por el UseMvc(), con la siguiente configuraci\u00f3n:<\/p>\n Estas l\u00edneas de c\u00f3digo lo que hacen es:<\/p>\n Una vez tenemos el arranque configurado, vamos a tunear el controlador. <\/strong>Para ello, en primer lugar cambiamos el ControllerBase por el ODataController, quedando nuestro Controller de la siguiente forma:<\/p>\n Posteriormente vamos a a\u00f1adir unos decoradores al m\u00e9todo, para lo que usaremos OData. Imaginad que tenemos un m\u00e9todo que nos devuelve todos los Avengers, quedando de la siguiente forma:<\/p>\n Si arrancamos nuestra API e invocamos al siguiente m\u00e9todo localhost\/api\/avenger, vemos que nos carga todos los \u00edtems que tenemos en Avengers. Ahora s\u00ed,\u00a0 usamos la sintaxis de OData para filtrar<\/strong>. Si tenemos un Avenger que se llama Hulk, por ejemplo,\u00a0 hacemos localhost\/api\/avenger?filter=$name eq \u2018Hulk\u2019<\/p>\n A nivel de la representaci\u00f3n de los datos la devoluci\u00f3n es la correcta, pero ahora bien, si analizamos las tripas y ponemos un punto de parada antes de que devolvamos los resultados, veremos lo siguiente:<\/p>\n Como pod\u00e9is ver, a pesar de que solamente hemos pedido un \u00fanico registro, se est\u00e1 trayendo toda la informaci\u00f3n de la tabla y despu\u00e9s, filtra los datos que he pedido. En mi opini\u00f3n, esta opci\u00f3n no es la m\u00e1s optima<\/strong>. Imaginad que tenemos una tabla con cantidad elevada de registros y solo queremos devolver dos. Por un lado, es posible que esa consulta pueda tener una penalizaci\u00f3n<\/strong> en cuanto a rendimiento y, por otro lado, tampoco tiene sentido hacer los filtros en el servidor cuando lo puede\/debe hacer la base de datos.<\/p>\n<\/h1>\n
Introducci\u00f3n<\/h1>\n
C\u00f3mo incorporar OData<\/h1>\n
\ndotnet add package Microsoft.AspNetCore.OData --version 7.4.1\r\n<\/code><\/pre>\n<\/div>\n\n services.AddOData();\r\n services.AddODataQueryFilter();\r\n services.AddMvc(options =>\r\n {\r\n options.EnableEndpointRouting = false;\r\n });\r\n<\/code><\/pre>\n<\/div>\n\n app.UseMvc(routeBuilder =>;\r\n {\r\n routeBuilder.EnableDependencyInjection();\r\n routeBuilder.Select().Filter().OrderBy().Expand().Count().MaxTop(10); \r\n routeBuilder.MapODataServiceRoute(\"api\", \"api\", GetEdmModel(app.ApplicationServices));\r\n });\r\n<\/code><\/pre>\n<\/div>\n\n
\n private static IEdmModel GetEdmModel(IServiceProvider serviceProvider)\r\n {\r\n ODataModelBuilder builder = new ODataConventionModelBuilder(serviceProvider);\r\n builder.EntitySet<Avenger>(\"Avenger\")\r\n .EntityType\r\n .Filter()\r\n .Count()\r\n .Expand()\r\n .OrderBy()\r\n .Page()\r\n .Select();\r\n return builder.GetEdmModel();\r\n }\r\n<\/code><\/pre>\n<\/div>\n\n public class AvengerController : ODataController\r\n {\r\n ...\r\n }\r\n<\/code><\/pre>\n<\/div>\n\n[ODataRoute]\r\n[EnableQuery(PageSize = 20, AllowedQueryOptions = AllowedQueryOptions.All)]\r\n[HttpGet]\r\npublic async Task<IActionResult> Get()\r\n {\r\n var result = await avengerDomain.GetAllAsync();\r\n if (result != null)\r\n {\r\n return Ok(result);\r\n }\r\n else\r\n {\r\n return NotFound();\r\n } \r\n }\r\n<\/code><\/pre>\n<\/div>\n![\"request](\"https:\/\/www.theavenger.dev\/posts\/images\/odata-entity\/RequestNormal.PNG\")
<\/p>\n![\"request](\"https:\/\/www.theavenger.dev\/posts\/images\/odata-entity\/RequestOdata.PNG\")
<\/p>\n\u00bfCu\u00e1l es el problema?<\/h1>\n
![\"resultado](\"https:\/\/www.theavenger.dev\/posts\/images\/odata-entity\/depurar.gif\")
<\/p>\n\u00bfC\u00f3mo se puede solucionar con OData?<\/h1>\n
![\"resultado](\"https:\/\/www.theavenger.dev\/posts\/images\/odata-entity\/ODataQueryOptions.gif\")
<\/p>\n![\"consulta](\"https:\/\/www.theavenger.dev\/posts\/images\/odata-entity\/query.PNG\")
<\/p>\n![\"error](\"https:\/\/www.theavenger.dev\/posts\/images\/odata-entity\/ErrorOdata.PNG\")
<\/p>\n