Hi Matt,

> I have a Job Business Object which will have a property for each field in the table (from scatter name ...)

That shouldn't have any impact on the decision. A Business object is meant to separate the application from the table. There's no direct relationship between what fields are in the job table and what values the job business object offers. For instance, you might store a history of a job in a different table, but it would be available from the job object. The job object might provide the date of the first and the last job. There are also fields in the job table that do not belong into a job object, at all, like a customer number. <s>

> But I want to go ahead and create a CustomerName property on the Job object

You want details of the customer of a job. Sounds like you want to access the customer object that is associated with the job. ;)

> so that I can just refer to that property on the Job object when displaying or reporting against it

So you de-normalize your BO structure as a development shortcut to save some code, don't you. <g> Why would you base the report on an object directly? My approach (which is just as wrong as everyone else's) would be to either have a method for the Job that returns a report cursor, or more likely, have a dedicated report objects that creates a cursor from the Job object, the Customer object, the CurrentUser object, the Company object, etc.

> I'm sure the more pure OO/BO approach would be

...to discuss this and offer dozens of contradicting opinions. <g>

> reference oJob.oCustomer.Name, right?

There's an OOP approach gaining momentum that discourages the use of multi-level object paths. Everything the consumer of an object needs should be there on the public interface. Other approaches obviously tout the minimum interface idea and want the opposite. There's also the idea of decoupling objects more. If a process needs data from a job and its customer, it should receive a job and a customer object.