Linq to LLBLGen Pro: feature highlights, part 1

re: Linq to LLBLGen Pro: feature highlights, part 1

BringerOD — Tue, 17 Jun 2008 23:07:35 GMT

@Frans

Thanks! I am always thinking about how to make my life easier.

Oh, and I agree with Jeff!

re: Linq to LLBLGen Pro: feature highlights, part 1

FransBouma — Tue, 17 Jun 2008 18:37:08 GMT

Thanks Jeff! :D

@Bryan: you could do:

public IQueryable GetCustomersQuery(LinqMetaData metaData)

{

return from c in metaData select c;

}

and then consume it elsewhere:

foreach (var v in GetCustomersQuery(linqMetaData))

{

// do something.

}

so you can pass it along as an IQueryable typed element. You can also return it as an ILLBLGenProQuery typed element, as all our queries have that type as well, so you can inject an adapter onto which db you want to execute the query at a later stage.

It's indeed a bit of a problem, and I think the only approach that's doable is the one described above, however it has the disadvantage that ... there's no type known at compile time. So consuming the query can for example be done through databinding at runtime, but if you want to read properties from the elements returned by the query, it is indeed a bit of a problem, which is caused by how Linq queries and anonymous types work I think. My guess is that Microsoft assumed most linq queries are consumed at the spot where they're created, which is logical concerning the fact that the design of Linq forces you to have all information and objects to execute the query INSIDE the query as well, so passing that across tiers isn't always a good thing.

re: Linq to LLBLGen Pro: feature highlights, part 1

Jeff Handley — Tue, 17 Jun 2008 16:30:58 GMT

Frans,

You're a freaking genius. Kudos sir, well done!

-Jeff

re: Linq to LLBLGen Pro: feature highlights, part 1

BringerOD — Tue, 17 Jun 2008 16:02:55 GMT

Frans,

I have a question for you regarding LINQ and a layer development approach. I return the results of a LINQ to LLBLGen query through the layers of the application. When I am sending results that match an entity collection it’s easy to pass them along, when it’s a query that does not match a entity collection, say a subset, or combination of entity’s, the process is more cumbersome.

Right now I have to create a class that represents the values being transferred. Do you have another approach to return collections based on none entity? Creating 100’s of classes that are used sometime just once to transfer data seems to smell a bit to me and I don’t know why. Not really an LLBLGen question, more a LINQ and layered development.