Hola Angel,
Gracias por tu respuesta. Para expresar mis especificaciones
estoy usando árboles de expresión de LINQ (System.Linq.Expressions,
System.Core), y creo que a vos también te servirían, ya que:
· Son independientes de la tecnología que tenga por abajo como vos
decís (salvo del propio framework de .NET, pero está en System.Core),
· Ya traen de fábrica un visitor
(System.Linq.Expressions.ExpressionVisitor). Vos podrías hacer subclases
para producir árboles para cada tecnología (ya tenés para SQL Server)
· Podés armar árboles estáticos muy fácilmente a partir de
lambdas, o dinámicos usando la API de Expression o helpers como el
PredicateBuilder que aparece en los links que pasaste.
Creo que lo que voy a tener que hacer es justamente un visitor para que haga
la traducción; cuando encuentre un nodo con una invocación a
ISpecification<T>.IsSatisfiedBy(), deberá reemplazarlo por la expresión
obtenida desde la especificación.
Tengo que leer un poco del tema; si avanzo les cuento.
Un abrazo.
De: [email protected] [mailto:[email protected]] En nombre de Angel
"Java" Lopez
Enviado el: miércoles, 25 de enero de 2012 7:15
Para: [email protected]
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: [email protected] [mailto:[email protected]] En nombre de Diego
Cepero
Enviado el: Tuesday, January 24, 2012 10:54 AM
Para: [email protected]
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
