Te respondí antes de ver este correo sí, esto anda bien:
pedidosPendientes = repositorioPedidos.Where(pedidoPendienteRecepcionSpec) incluso pude desarrollar soporte para operadores lógicos a nivel especificación: pedidosPendientesPrioritarios = repositorioPedidos.Where(pedidoPendienteRecepcionSpec && pedidoPrioritarioSpec) pero más allá de que así me sirve, quería dar soporte a las dos sintaxis de LINQ. De: puntonet@mug.org.ar [mailto:puntonet@mug.org.ar] En nombre de Angel "Java" Lopez Enviado el: miércoles, 25 de enero de 2012 9:33 Para: puntonet@mug.org.ar Asunto: [puntonet] LINQ to Entities & Specifications Ah! Pregunta: Una cosa que no entendí. Si habías extendido tu especificación para producir un Expression<Func<Pedido, bool>> Por que no quedarse con: rows.where(tuespecificacion) ? No funciona en Linq To Entities? Yo prácticamente no uso la forma b) Para mi Linq es los métodos de extension Nos leemos! Angel "Java" Lopez http://www.ajlopez.com/ http://twitter.com/ajlopez De: puntonet@mug.org.ar [mailto:puntonet@mug.org.ar] En nombre de Angel "Java" Lopez Enviado el: miércoles, 25 de enero de 2012 7:15 Para: puntonet@mug.org.ar Asunto: [puntonet] LINQ to Entities & Specifications Hola gente! Diego, tengo un caso parecido, pero que todavia no llegue a necesitar. Tengo condiciones a cumplir por registros, que pueden hoy estar almacenados en SQL, como en SQL Azure, como en PiruloData o SuperDuperNoSql, hasta pueden estar simplemente en memoria, quizás distribuida. Esas condiciones se describen casi como tus especificaciones. Con condiciones lógicas, que no saben del store que los tiene. Todavia no necesite LINQ, pero me prepare para si lo necesito (creo que no, pero hay que estar preparado ;-) Entonces investigue: <http://stackoverflow.com/questions/877034/linq-predicatebuilder-multiple-or s-newbie-q> http://stackoverflow.com/questions/877034/linq-predicatebuilder-multiple-ors -newbie-q http://www.codeproject.com/Articles/28580/LINQ-and-Dynamic-Predicate-Constru ction-at-Runtime Mi idea es que mis condiciones (tus especificaciones) sean visitadas por un Visitor (en este caso un LinqVisitor) que al final produzca un predicado Predicate<TuTipo>, o Func<TuTipo,bool> Ese predicado lo aplicaría a un rows.Where(elpredicadoqueconseguidelvisitor). Entonces, por CADA TECNOLOGIA que tenga por abajo, habrá un visitor que produzca lo que tiene que producir para conseguir DELEGAR en la tecnología de abajo. En mi caso, creo que puedo evitar LINQ: puedo hacer que el visitor genere directamente la sentencia WHERE a entregar a la tecnología de abajo, un MS SQL Server. Me temo que no hay repo publico. Debo tener algo asi en mis proyectos públicos, pero nada parecido a esto que describo; debería escribir post ;-) Nos leemos! Angel Java Lopez http://www.ajlopez.com http://twitter.com/ajlopez De: puntonet@mug.org.ar [mailto:puntonet@mug.org.ar] En nombre de Diego Cepero Enviado el: Tuesday, January 24, 2012 10:54 AM Para: puntonet@mug.org.ar Asunto: [puntonet] LINQ to Entities & Specifications Buen día, Estoy tratando de desarrollar un soporte de especificaciones [1], con la intención de que sirvan tanto para ser evaluadas directamente como para ser utilizadas en el WHERE de una consulta de Linq to entities, es decir: (a) if (pedidoPendienteRecepcionSpec.IsSatisfiedBy(unPedido)) o también: (b) pedidosPendientes = (from p in repositorioPedidos where pedidoPendienteRecepcionSpec.IsSatisfiedBy(p)) Lo que ocurre, y es lógico, es que Linq to entities no sabe traducir la llamada a la función IsSatisfiedBy() a TSQL. Lo que sí puedo hacer es algo así: pedidosPendientes = repositorioPedidos.Where(pedidoPendienteRecepcionSpec) porque sobrecargué en la especificación el operador de conversión de tipos para que sea implícitamente convertible a Expression<Func<Pedido, bool>> ¿Alguien sabe cómo puedo extender Linq to Entities para poder incluir las llamadas a .IsSatisfiedBy() como muestro en (b)? Estoy usando Entity Framework Code-First. Gracias, saludos. Diego Cepero. [1] http://martinfowler.com/apsupp/spec.pdf No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.454 / Virus Database: 271.1.1/4164 - Release Date: 01/24/12 19:34:00
