Por un lado, yo me he bajado el NHibernate.Linq que hay junto con el
download de NHibernate 2.1.2 ... y tiene QueryOptions. Al ver el
objeto, pensaba que servia para especificar si quería cachear la
consulta, etc... no he seguido el código hasta el final.

Por otro lado, no me hace decidirme entre crear métodos específicos
para los daos o usar Specifications. Descarto la posibilidad de usar
LINQ desde cualquier punto por no poder acotar el ámbito de las
consultas y perder la posibilidad de testearlo todo.

Creo que me basaré en métodos para cada consulta, así será más fácil
para los programadores y más acotado. Aunque me gusta más el uso de
Specifications, creo que agrega complejidad, y quiero que lo tengan
fácil. Total, la especificación con linq simplemente me parece una
forma de acotar los criterios usando linq y evitar tenerlo disperso
por el código.

¿Estamos de acuerdo? :)



On 14 jul, 17:38, José F. Romaniello <[email protected]> wrote:
> in line
>
> El 14 de julio de 2010 12:28, Juan Cuello <[email protected]> escribió:
>
> > Suponiendo que usamos Daos o repositorios, el uso de linq debería
> > quedar encapsulado en los métodos de la implementación de los daos (o
> > repositorios) o debería exponerse INHibernateQueryable<T> o
> > IOrderedQueryable<T> para que se pueda explotar el linq desde
> > cualquier punto?
>
> nunca INhibernateQueryable, ni IOrderedQueryable. A lo sumo IQueryable.
>
>
>
> > 1) Exponer INHibernateQueryable<T> tiene el problema de que se
> > necesita desde donde se use el dao una referencia a NHibernate.Linq y
> > a NHibernate, por tanto, si tenemos un ensamblado con las interfaces
> > de los Daos, creo que no es una solución correcta, ya que sometemos
> > las interfaces a la tecnología subyacente.
>
> nunca INHibernateQueryable.
>
> > 2) Exponer IOrderedQueryable<T> elimina la necesidad de referencias
> > pero perdemos la capacidad de especificar las QueryOptions ¿?
>
> Para que usas QueryOptions vos?
>
> > 3) Encapsular la consulta linq dentro de un método del dao elimina los
> > problemas 1 y 2, pero deberemos crear una función para cada consulta
> > con sus diferentes parámetros, cosa que nos podemos evitar permitiendo
> > el uso de linq. Aunque de esta forma acotamos el ámbito al realizar
> > tests de los Daos y podemos evitar las limitaciones que tenga la
> > librería.
>
> Muy buena pregunta, ahora te toca 
> leer:http://fabiomaulo.blogspot.com/2010/07/enhanced-query-object.htmlhttp://jfromaniello.blogspot.com/2010/06/linqspecs-why.html
>
>
>
>
>
>
>
> > SUGERENCIA
>
> > En NHibernateExtensions hay una serie de funciones y, en una en
> > especial:
>
> >        public static INHibernateQueryable<T> Linq<T>(this ISession session)
> >                {
> >                        QueryOptions options = new QueryOptions();
> >                        return new Query<T>(new
> > NHibernateQueryProvider(session, options),
> > options);
> >                }
>
> >  Se crea QueryOptions sin posibilidad de especificar opciones. ¿Sería
> > incorrecto crear otra extensión del tipo?:
>
> >        public static INHibernateQueryable<T> Linq<T>(this ISession session,
> > QueryOptions options)
> >                {
> >                        QueryOptions options = options ?? new
> > QueryOptions();
> >                        return new Query<T>(new
> > NHibernateQueryProvider(session, options),
> > options);
> >                }
>
> > Para dar la posibilidad de especificar las opciones en la misma
> > extensión? O se debe hacer de otra forma la especificación de
> > opciones?
>
> > Muchas gracias
>
> Como te pregunte antes , no se para que cosas usas QueryOptions... Creo que
> ni si quiera esta en el nuevo provider de linq.

-- 
Para escribir al Grupo, hágalo a esta dirección: 
[email protected]
Para más, visite: http://groups.google.com/group/NHibernate-Hispano

Responder a