Aaron,

Greg's response is right on target.  The truth is that a framework is supposed to help in the area of "best-practices" as well as many other things.  Though this wouldn't be that difficult to implement, I think that it would be overused and then there would be a whole series of questions about performance out here...so like Greg, said, it is easy to add and you can do it very easily, but this is one of those things that we have thought about putting in before and keep coming back around to, "it's probably not a good idea."

Thanks Greg.

I had thought about subclassing the Business Layer and using the FieldEnums to replace the SELECT * as we intend to use Notification Services.

As you say it isn't a big job, I was just being lazy

By the way, is this forum always so quick with a response? I have come from one where you are lucky to get a reply in days let alone minutes!

Thanks,

Aaron

I can't say why the SF team didn't implement this, but I can guess. There is just too much variation in how you might fill a BO for this to make sense in a framework. Also, it is very easy to implement. Third it is very easy to implement so you don't have to implement it for every BO that might need it.



To implement it so you don't have to keep adding the same method to all your list BOs, you could just subclass the BusinessLayer, then inherit from you new class. I.e. (in vb)





To use:





Hope this helps!

I am new here so please excuse my ignorance

I have been reading through the help file and I thought it would be a benefit to offer a built-in FillAll() population method which simply reads all records into the BO. I can see quite a large no of BOs in our application (i.e. lookup lists, etc.) that would benefit from this. I know I can add my own FillAll() to each BO but, as I am lazy, it would be nice if it was built-in

Is there a reason why you have decided not to implement it?

Thanks,

Aaron