Hi all. I'm trying to evaluate this product for use in a project and so am very new to the nuances of your labyrinthine namespaces & classes.

I have a user control designed to display collections in a DGV and it has dynamic filtering and sorting functionalities built in. I built this for an earlier DAL prototype (my own) so that it could receive a collection of entity objects that implement an interface (I called it IEntity - but don't confuse it for your version of the interface). This meant that I could pass into it Employees, Orders, Customers, etc. and it did not need to care what the specific type of the entity was so long as it implemented IEntity. Of course, this was because IEntity exposed data operation functions like Save and Delete. My generic collection was retrieved from an application facade on my business layer so it came as a package that did not expose anything more than the required members for the UI to do its thing.

Now being faced with having to redesign the extended grid control to work with your classes I find that I'm unsure how to re-create this architecture. I see EmployeeCollection and CustomerCollection but how do I reference those collection classes generically so that I have only one ListGrid control and not EmployeeListGrid, CustomerListGrid, etc.

So if I were to have a private member of my user control ListGrid class that stored the collection object how would I declare it so that when I call a member of it (e.g. a function) it would work for all entity types and I woudl not need to know which specific type I was dealing with.

Thanks in advance.

DB

p.s. Sorry... the title does not do the question justice but I couldn't think of a better way to say it.

DigBoy wrote:

Hi all. I'm trying to evaluate this product for use in a project and so am very new to the nuances of your labyrinthine namespaces & classes.

labyrinthine?

DigBoy wrote:

I have a user control designed to display collections in a DGV and it has dynamic filtering and sorting functionalities built in. I built this for an earlier DAL prototype (my own) so that it could receive a collection of entity objects that implement an interface (I called it IEntity - but don't confuse it for your version of the interface). This meant that I could pass into it Employees, Orders, Customers, etc. and it did not need to care what the specific type of the entity was so long as it implemented IEntity. Of course, this was because IEntity exposed data operation functions like Save and Delete. My generic collection was retrieved from an application facade on my business layer so it came as a package that did not expose anything more than the required members for the UI to do its thing.

In LLBLGen Pro these light-weight objects you mention (no persistence logic inside them) are used in the Adapter TemplateSet, you are using (I guess) the SelfServicing TemplateSet.

DigBoy wrote:

So if I were to have a private member of my user control ListGrid class that stored the collection object how would I declare it so that when I call a member of it (e.g. a function) it would work for all entity types and I woudl not need to know which specific type I was dealing with.

You can go with the **IEntityCollection **interface. Hope this links would be helpful: http://llblgen.com/tinyforum/Messages.aspx?ThreadID=10833 http://llblgen.com/tinyforum/Messages.aspx?ThreadID=13293

David -- thanks for the response. IEntityCollection is likely just what I was looking for (at least it made the compiler errors go away for now

I did start with the SelfServicing option so I could start more simply with understanding what LLBLGen generates. I'll remember to include that in future posts.

As for the term labyrithine... I think it aptly describes the generated framework within which the generated code lives. It reminds me a little of my first day exploring the .NET framework while trying to find just the right class for what I needed. But don't get me wrong. It all seems very well organized and the classes are very well named -- a very impressive product.

Thanks again!