>>>Hi
>>>
>>>I have a collection of data-objects in my app, I want to use these data-objects to hold certain values to keep things in the app up to date. Is this a good idea?
>>>
>>>For example, I have a USER data-object, that can add/edit/delete records, but also contains functions that can be called by it's parent, and may also validate usernames/passwords and also hold the currently logged in userid, userlevel etc.etc.
>>
>>Generally speaking, it sounds to me like you are describing an ordinary business object. (It would talk to a data object that does the actual data-related stuff like add, delete, save records, say).
>>
>>So, yeah. In my mind a user business object would have this functionality.
>
>So, if I was writing a 3-tier app, my business object would obviously reside in the middle-tier, but does that mean that the data-object does too? Or is that part of the data-layer?

Simplifying the terms in VFP tools...put data related logic in their own classes (non-visual), business logic in their own, non-visual classes, and put UI-related logic in their own classes. If you count the actual data store as a tier, then that makes 4, by my count. So, the data object resides in its own tier, which might be stored procs, by the way.

The way I think of it, the business and data objects will look somewhat similar. Both will have, for example, a validation method. But the business object will validate based on "real-life" rules, and the data object will validate based on data-specific rules. So, for example, if you have textbox that displays a customer's SSN, the customer business object will validate that it's not empty (rule that you have to get the SSN), but the data object may validate that it's in the format 999-99-9999 or that it's not a duplicate in the system.

Which rule is a business rule and which is a data rule is a gray area, I believe. I break it up by following the rule of thumb of, if the client states something as a rule for how the app will work, it's a business rule; if I care about it, but he doesn't, then it's a data rule (such as Referential Integrity rules).