Hola,
Aclaro que es una lista de entidades. Cada entidad contiene varios
objetos en relación 1 a 1, por tanto, si recorro la lista y acceso a
ese objeto de cada elemento, estoy haciendo una nueva consulta a base
de datos para cargar el objeto dependiente. Algo así como:
Teniendo esta clase:
public class DataGridRecinte
{
public decimal ID { get; set; }
public string IdentificacioParc { get; set; }
public bool IsValidat { get; set; }
public string SecaRegadiu { get; set; }
public string SupConreada { get; set; }
public string CodiProducte { get; set; }
public List<string> recAjuts;
}
Siendo "data" la lista de entidades de tipo DunRecinte
(List<DunRecinte>) :
IEnumerable<DataGridRecinte> Taularecintes =
from r in data
select new
DataGridRecinte
{
ID = r.ID,
IdentificacioParc = CalcularIdentificacioParcela(r),
recAjuts =
AfegirAjutsALlista(r.RecinteAjuts),
CodiProducte
= GetCodiProducte(r.Varietat),
SecaRegadiu
= r.SecaRegadiuDescripcio,
SupConreada
= FormatSupCultiu(r.SupConreada.GetValueOrDefault(0)),
IsValidat =
GeneralUtils.ParseBool(r.IsValidat)
};
Cada función CalcularIdentificacioParcela, AfegirAjutsALlista, accede
a una subentidad, por tanto, se está haciendo una nueva consulta. Lo
que quisiera yo es obtener directamente la lista
IEnumerable<DataGridRecinte> (o List< DataGridRecinte>). Por eso,
posiblemente lo mejor sería crear la entidad DataGridRecinte,
mapearla, y especificar la select a hacer. De esa forma, con una sola
consulta a base de datos tendría el resultado deseado.
¿Consideráis que es la mejor forma? Además, el resultado es de sólo
lectura... Si así es, me podéis decir un sitio donde haya un ejemplo
de especificación de la select?
¿Alguna otra solución?
Muchas gracias
On 14 dic, 15:39, Fabio Maulo <[email protected]> wrote:
> solo para recordarles que esos "join fetch" funciona si las collection son
> <set>
>
> El 14 de diciembre de 2009 11:26, José F. Romaniello <[email protected]
>
>
>
>
>
> > escribió:
> > Un ejemplo sería :
>
> > Invoice que tiene las propiedades Customer, Payment, Contact. Las tres son
> > LazyLoad y eso esta bien, pero para esa consulta que tenes que mostrar ese
> > dato calculado que depende de los tres, y ahi tenemos un problema.
>
> > Entonces como hacemos?
>
> > from Invoice i
> > inner join fetch i.Customer
> > inner join fetch i.Payment
> > inner join fetch i.Contact
>
> > 3 inner join fetch es un poco mucho.... Pero.
>
> > Si en todo tu sistema, por todos lados tenes que mostrar esa propiedad
> > calculada, evaluaría hacerlo de otra forma. Pero vos dijiste que era para
> > mostrar en una grilla paginado solamente.
>
> > Saludos
>
> > El 14 de diciembre de 2009 11:15, Carlos Peix
> > <[email protected]>escribió:
>
> > Hola Juan,
>
> >> Por que 300 consultas a la base de datos? si tenes tres colecciones hijas
> >> deberias tener 3 consultas que devuelven 100 elementos cada una (a menos
> >> que
> >> me equivoque por mucho)
>
> >> La primera recomendacion seria no realizar optimizaciones (como la carga
> >> "eager" de las colecciones) hasta que no se compruebe que es necesario.
>
> >> Como siempre, NH no hace magia y si es necesario que tengas un cache de la
> >> suma en la entidad padre, pues tendras que hacerlo de la misma manera y
> >> persistirlo. Esta opcion deberias usarla en caso extremo ya que implica
> >> almacenamiento redundante de informacion, aunque con un buen diseño de los
> >> objetos, no deberia ser muy riesgoso.
>
> >> ----------------------------------
> >> Carlos Peix
>
> >> 2009/12/14 Juan Cuello <[email protected]>
>
> >> Muchas gracias a ambos. Lo de paginación lo tengo solucionado gracias
> >>> a vuestras instrucciones. Uso Oracle 10g.
>
> >>> El problema de propiedades calculadas es que los programadores, para
> >>> obtener dicho valor, accedían a las subentidades (carga lazy)
> >>> provocando que, en una lista de 100 elementos, que se accede a 3
> >>> subentidades por elemento, hablamos de 300 consultas a base de
> >>> datos...malo malo.
>
> >>> La idea era especificar la select de carga de dicha entidad haciendo
> >>> los joins que corresponden y mapeando esos valores, de forma que al
> >>> cargar la lista, directamente tendría los valores calculados en esas
> >>> propiedades y me ahorraba accesos a bbdd. Pondría estas propiedades en
> >>> insert="false" update="false" y listo...
>
> >>> ¿Es buena idea hacerlo de esa forma? ¿Alguna idea mejor? ¿Tenéis algún
> >>> ejemplo de especificación de select para la carga de una entidad?
>
> >>> Muchas gracias
>
> >>> On 12 dic, 13:38, José F. Romaniello <[email protected]> wrote:
> >>> > Y otra cosa, en unhaddins hay algo:
> >>>http://code.google.com/p/unhaddins/source/browse/#svn/trunk/uNhAddIns...
>
> >>> > Aunque para mi, todo el problema el problema de Paginación/Sorting y
> >>> > Filtering, se puede resolver con dos funciones en un servicio de la
> >>> > siguiente forma:
>
> >>> > ICollection<TEntity> GetPage(int size, int pageNumber,
> >>> > Expression<Func<TEntity, bool>> predicate, params Func<TEntity,
> >>> object>[]
> >>> > order);
> >>> > int GetLastPageNumber(int size, Expression<Func<TEntity, bool>>
> >>> predicate);
>
> >>> > <
> >>>http://code.google.com/p/unhaddins/source/browse/#svn/trunk/uNhAddIns..
> >>> .>Y
> >>> > son dos funciones diferentes por que GetLastPageNumber, se llama
> >>> unicamente
> >>> > cuuando cambia el predicado. Eso da la libertad de en el presenter
> >>> hacer
> >>> > cualquier cosa.
>
> >>> --
> >>> Para escribir al Grupo, hágalo a esta dirección:
> >>> [email protected]
> >>> Para más, visite:http://groups.google.com/group/NHibernate-Hispano
>
> >> --
> >> Para escribir al Grupo, hágalo a esta dirección:
> >> [email protected]
> >> Para más, visite:http://groups.google.com/group/NHibernate-Hispano
>
> > --
> > Para escribir al Grupo, hágalo a esta dirección:
> > [email protected]
> > Para más, visite:http://groups.google.com/group/NHibernate-Hispano
>
> --
> Fabio Maulo
--
Para escribir al Grupo, hágalo a esta dirección:
[email protected]
Para más, visite: http://groups.google.com/group/NHibernate-Hispano
