But Jim,

Couldn't one also code to add a property if a new field was detected six months later?

Cheers,

Jim N

>Josh,
>
>I don't necessarily say that accessing properties is a bad thing, it some situaitons it is the simplest interface you can build. However, let me use a better example to explain the problem.
>
>We build a customer object (business object) and use its properties to store the current records field values. This object has Company, Addr, City etc. properties.
>
>Second scenario, we build the same customer object except it has a GetFldValue and SetFldValue methods which accept the field name as a parameter.
>
>Initially the two designs are similar in complexity. The property design even seems a little cleaner (less code, more direct etc.).
>
>However, six months after release a field is added to the customer table in the database. The property design requires that the database by modified (to add the field), the business object be modified (to add the new porperty), and the UI be modified (to display the enw field).
>
>With the Get/Set methods you only need to modify two of the three tiers, because the business object can be coded to try to get whatever field value was requested without restriction. You add the field to the database, and modify the UI to display the field and that's it. No modifications required to the business object.