In memory transform is not what I'm after. In fact that's what I am
trying to remedy without a lot of code repetition. I am now heading
in this direction:
session.Linq<Foo>() .Select(Foo.GetDtoSelector()).ToList();
public static Func<Foo, FooDto> GetDtoSelector()
{
return f => new FooDto
{
Id = f.Id,
Bar= f.Bar
};
}
This allows NHibernate.Linq to do the transform in SQL while also
allowing reuse of the transformer.
This leaves only one concern. What if I have FooDetailDto and
FooListDto which inherit from FooDto? How do I avoid repetition? I
have asked that here:
http://stackoverflow.com/questions/222511/refactor-to-eliminate-repetition-in-lamba-expression.
On Oct 20, 4:30 pm, "Ayende Rahien" <[EMAIL PROTECTED]> wrote:
> The problem is that you would need some way of letting NH know that this is
> a method that should run on the results, rather than transform them.The
> first statement will generate
> select id, bar from FooTbl
>
> The second will generate
> select * from FooTbl
>
> And do the transform in memory, which might be expensive.
>
> On Mon, Oct 20, 2008 at 11:24 PM, Tim Scott <[EMAIL PROTECTED]> wrote:
>
> > Currently in NH.Linq we can do this:
>
> > (from f in session.Linq<Foo>() select new FooDto { Id = f.Id, Bar =
> > f.Bar }).ToList();
>
> > Is it conceivable to extend NH.Linq to do the same thing like so?
>
> > (from f in session.Linq<Foo>() select f.TransFormToDto()).ToList();
>
> > That is...to factor out projection transform to a method (not
> > necessarily on the Foo class). It seems this would have great DRYness
> > value.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"NHibernate Contrib - Development Group" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com.ar/group/nhcdevs?hl=en
-~----------~----~----~----~------~----~------~--~---
