Hello,

I'm working with asp.net actually. It happen really often that I need a datasource with many related entities. Almost every pages has a grid and more than the half of them need related entities (other than simple value tables).

Actually I use either TypedList, TypedView or SqlDataSource (performance).

• I would prefer not to use SqlDatasource.
• I can also write code on event "PerformSelect" but I loose easy deisgn time data binding in grid (fields are unknown at design time).
• I can use TypedList or TypedView but I have to do the round trip of code generation

I wonder if there is plan to do a version of LLBLGenDataSource to achieve design time binding (field know) with prefetched path entities in the future (Same as SqlDataSource) ? ... without needing to do the TypedList or TypedView roundtrip

Kind of LLBLGenDataSource property to enter prefetchedPath and if this property is not null then it return a DataSource with all entities in the prefetch path ???

Kind of LLBLGenDataSource property to enter prefetchedPath

There is a prefetchPath property, but this is used from code behind, as you have to create a PrefetchPath object and start adding prefecthPathElements to it.

and if this property is not null then it return a DataSource with all entities in the prefetch path ???

I'm not sure I understand this part.

Hello,

I know we can use prefetch path in "PerformSelect", I wrote it.

I just ask if there is any future development planned to add the possibility to select more than only one entities in the LLBLGenDataSource.

It would be really nice, at design time, when using LLBLGenDataSource, to be able to choose from any fields from many related table. Either if we use prefetchPath in "PerformSelect" event, I'm pretty sure, that at design time, we can only see fields from the entity defined in the EntityName property of the LLBLGenDataSource control, not all the ones from the prefetchPath. Am I right ? I haven't test it but I hardly can't see how it could call the performSelect at deisgn time...

About : "and if this property is not null then it return a DataSource with all entities in the prefetch path ??? " .... It was only part of suggested solution ... king of behavior if there would be a way to enter preftched path at design time in a property of the control.

Well normally this can be done using more than one LLBLGenProDataSource on more than one bound controls, with SelectParameters linking them to each other.

So for example if you select a customer from the Customers Grid, its orders would automatically appear in another Grid.

And this can chain down to an infinite number of DataSources and Controls.

The problem of PrefetchPaths, is that sometimes you are prefetching a m:1 relation and sometimes it's 1:m So for the Customer and Orders, you would have multiple Orders for the same customer, and this can't be displayed in a flat grid.

The other options is to use "Fields on related fields option" from LLBLGen Pro Designer, and populate them at runtime using prefetchPaths.

Also for read only lists, you can use TypedLists.

Further than that I don't know how prefetchPaths can be implemented in LLBLGenProDataSource to be managed at Design Time.

I'm agree with everything you wrote. It's all true. I already considered that.

The problem is to flatten (see multiple entities as a flat one). Yes its not really object oriented. But it's life. At least, I hardly thing that it happen really often that we need to flatten entities to put in only one grid. The user can then use filter, sort and so on.

To use that, like I said in my first message, we need a way to flatten. But to be nice to work with, we need to have fields available at design time. Otherwise we need to make a round trip of code generation each time we want to modify a "TypedList" or "TypedView". And also, it is time consuming and create a large amount of very specifics TypeList and typedView. We need a way to do the same as SqlDataSource !!!!!!!! but in a LLBLGen manner !!!!!! (a better and clean way than microsoft !!!)

Does it make sense ?

Isn't this something you already proposed some time ago? I.e.: a design time helper which was solely there to setup grids? As the list itself is always readonly.

mmm, yes! I think so ! In fact yes ! I already proposed that.

Althought I may appear confident, I'm always questionning myself. When I asked the option of flat datasource, I already had many cases where I needed this cool feature and thought it would be a really nice thing to have.

Few months later, I'm kind of very sure that it would be a necessity for a well structured application that meets high cohesion and low coupling, but I have some doubt about the advantages of doing it... My main doubt come from my ignorance of EntityFrameWork and WPF-WCF (if those new "technologies" would replace existing way of managing data). I also have another concern, I 'm not sure that a lots of people are using LLBLGen for web development. I would see more advantages or using it for Windows-Form application... Then, the importance of that feature become a low priority mixing with all other wanted features that meets more users needs.

In conclusion... I mainly want to say that I'm more confident about the importance of that feature and I also wanted to test the audience to see if other people would have appreciate that feature. (It doesn't appear really needed )

Thanks for hearing and have a very nice week !!! I will try not to ask it a 3rd time...

....also...

There is no perfect solution. Microsoft architect still think flat, the day they will think in 3D in an object way then it will be simplier. The Hypotetic LLBLGen solution will have to deal with name clashing and so on, I don't see a perfect solution now for the way datasource are managed now. I will sleep on that, and if I found a solution in my dream, I will tell you my vision...

Heh You do that

We'll consider something for v3, based on your earlier request. If we come up with something, we'll add it. If it meets a lot of issues, we won't.

Thanks !