This thread - http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=15320&HighLight=1 - discussed using LLBLGenProDataSource2 with a Dynamic TypedList and everyone there came to the conclusion it wasn't sensible and just filling the control's data source directly was best.

Using the LLBLGenProDataSource2 even for select has the advantage for me that I don't need to test it - asp.net handles getting the data itself. This simplifies unit testing and it is great for TypedLists/Views or Entities.

Afaik I can't select fields from a TypedList or TypedView. This causes complications when I need to do a Group By on the TypedList where the criteria I want to filter by shouldn't appear in the resultset.

In fact, I haven't managed to get this to work at all after many hours of trying, so I now use a Dynamic TypedList created from an Entity based on a view (which is a UNION query to make matters worse:-). This means I have to get the data in code, which in turn adds a unit testing implication of having to mock something (haven't worked out what yet!).

A Dynamic TypedList is exactly what it says - dynamic. I have to create it for it to exist rather than being able to create a definition that can then be filled using the AdapterToUse of the LLBLGenProDataSource2.

Is creating a definition for a Dynamic TypedList that could be used in a LLBLGenProDataSource2 instance something that can be done in a way I haven't discovered yet, or could it go on a wishlist for a future release?

Doesn't creating a definition for a DynamicList immediatly mean that it is a Typedlist - the whole point of Dynamic lists being that they are dynamic and don't need definitions. I'm not sure I can see the benefit in what you are asking ?

Matt

No. The Dynamic TypedList only comes into being after creating it with adapter.FetchTypedList(...), whereas a TypedList is a standalone class that is created and fetched by asp.net without any code from me and exists independently of the database.

Unit testing and simplicity of code are the main objectives for me, although the other thread pointed out some further benefits of using LLBLGenProDataSource2 also.

All I need to do is set the FilterToUse, GroupByToUse and AdapterToUse (if not the default) and away it goes. I don't need to worry about fetching the data or databinding as asp.net does that for me. My testing is thus limited to ensuring I can supply appropriate objects for these properties rather than having to mock adapter.FetchTypedList(...) - which I haven't worked out how to do yet. (This is Supervising Controller pattern I guess).

In practice, creating models, views and presenters using this approach has been dead easy using TypedLists and I am so pleased I want to do it with more complex database accesses that don't fit the TypedList or TypedView approach - hence the need to use Dynamic TypedLists.

For now, I am creating the Dynamic TypeLists in my model and getting a plain old ObjectDataSource (aka POO:-) to call the select method in my model directly. It isn't too bad, but it still means I need to mock out the database call if I want full test coverage. Any ideas on that aspect are equally welcome of course.

The problem is that a dynamic list created in code has no definition, so it can't be used at design time: there's no definition to design the declarative code (HTML) with. With a typed list, there is a static definition, it has columns to examine etc. With a dynamic list, that's not the case.

So you won't be able to design a page with for example a grid and a datasourcecontrol with the dynamic list: the columns are unknown.

This means (but correct me if I have misunderstood you) that the columns for example in a bound grid are discovered at runtime in your case. The code to setup the datasourcecontrol with a filter/adapter and groupby is not really less code than fetching the list and set the datasource of the grid + calling databind.

Btw, I didn't get this remark:

Afaik I can't select fields from a TypedList or TypedView. This causes complications when I need to do a Group By on the TypedList where the criteria I want to filter by shouldn't appear in the resultset.

It is possible to obtain the list of fields in a typedlist or typedview. Grouping on fields not in the resultset doesn't work, as that will give bad sql. Filtering can be done with whatever field you want, just create the field in a filter and you're done. The only drawback is that if you use aliased entities in the typedlist, you need to know the aliases in the code.

Thanks for the explanations.

Yes, my main problem turned out to needing to group by on one field and do an aggregate for another in a TypedView (on a union query) while filtering on 3 separate fields in that union query.

The filter is on 3 fields that shouldn't appear in the select statement as that would mean adding them to the group by clause, making the resultset wrong.

The remark of mine you quote was obscure without code I agree.

Are you saying I could create the TypedView with just 2 columns from a real view which has the 2 columns I want to return and 3 columns to filter on, then use FilterToUse for the 3 filters and GroupByToUse to do my grouping and aggregate? I'll try it.

In the meantime, I have mocked the adapter.FetchTypedList method and that works fine, so now I am simply chasing simpler code and testing using LLBLGenProDataSource2 instead of an ObjectDataSource.

It all turned out nice and simply. I created

1 a union view which contained the columns needed to deliver to the web page plus the columns needed to filter and sort. 2 an Entity from this view 3 a TypedList from the entity containing only the fields needed for the web page - one field was a count aggregate 4 an LLBLGenProDataSource2 as normal and set the FilterToUse, AdapterToUse, GroupByToUse properties in the select method.

Thanks for all the help and suggestions.

Neil