I notice in the self-servicing code that there is a shared function in the entitycollection called GetMultiAsDataTable.

Why isn't there a similar shared function called GetMulti()?

My biggest complaint about LLBLGen is that everything takes a lot more code to do than with other generators I've used, and adding shared functions like this would be a step in the right direction

For example, instead of coding this: Dim customers As New TblCustCollection customers.GetMulti(Nothing) For Each customer As TblCustEntity In customers

I'd rather code this (notice the lack of parameters to GetMulti): For Each customer As TblCustEntity In TblCustCollection.GetMulti()

This probably seems trivial to you, but I guess I've been spoiled by some of the other generators. On top of that, better readability is never a bad thing.

GetMulti is not static because it uses the set transaction object of the base class. Therefore it's part of the generated typed collection code. The code is not made generic (i.e. moved to the generic base class) because it has to work with a typed DAO Object.

That's why the method is there and that's why you can't share teh method among your other entities.

Selfservicing is more verbose than adapter btw. Most functionality that is generated per entity for selfservicing is generic and shared among all entities in adapter. The reason this is not done for selfservicing is because as said, everything is typed and generic code AND typed code is not something that is doable in .NET 1.1 (or you have to jump through hoops a lot which will make the code less readable. )

(note: of course selfservicing could be made more generic, with a lot more overloads of GetMulti, static stuff etc. but it was a design choice to make everything typed and avoid casts as much as possible. Personally I find having the method GetMulti both statically and non-statically (which would have been the result) pretty bad)

I think no matter what model you choose. In the end, simply using LLBLgen means less code "You" have to write by hand, i.e. try writing your own DAL by hand, it stinks.

From a readability stand point, I started with VBA, then learned VB, then VB.NET, now I write in C#. If you want readablity, use C#, IMO it is tons cleaner and a lot less wordy.

As far as less code, I have found that typically, taking an abstract approach to development using good OOD techniques = less code.

For what it's worth, those are my 2 cents.