Rex,

>We have a .Net contractor that uses business object to encapsulate actor information. He says that the business object should have properties for only the table fields that are to be displayed, but I have always used business objects with all table fields represented as properties. He says that he does this to conserve memory, but my understanding of business objects is that the objects controls and encapsulates all information regarding the associated actor.

It definitely sounds like a bad design for all the reasons mentioned by the others who've responded to your post. You actually don't need to surface *any* of the fields in the table as public properties, whether they're displayed or not. You end up with a more flexible design if you have business object methods return data readers, datasets, or XML instead. If you make all of your table fields public properties, you break encapsulation, and expose your data to the outside world. In contrast, if you create methods that return data, you can limit what you return to a consumer of your object--and can even vary it based on permissions.

Regards,