>>>>>Personally, I don't favour this approach as I like to separate business logic out of the database. This makes it easier to port your application onto other databases etc.
>>>>
>>>>I don't understand this. How can you separate business logic away from the database? By definition the database is a business entity. It seems to me that by keeping the business logic with the database and excluded from any app, you can use several different apps with the same database.
>>>
>>>What happens if you have to switch databases? Pulling the logic out of the database and the main app allows it to be used by multiple apps and multiple databases.
>>
>>Hi Joel,
>>I feel like I'm missing something. Maybe I'm doing something wrong.
>>How can you separate the logic from the database? How could logic work on 2 different databases?
>>Can you give me a small example?
>
>With the framework I use, validation is done in code through information entered into a data dictionary. Basically, validation is handled before the data hits the database. For example, if you were saving a customer record, you might have an oCustomer object with a Save method. oCustomer.Save() calls the applicable validation routines, which determine if the data should be written to the database. Of course, all data interaction needs to be done through the oCustomer object. If you want to deal with the database directly, then this won't work.
>
>n-Tier frameworks typically look something like this: UI layer->Business Objects->Data Access Object->Database. Validation and business process code usually reside in a business object. The data access object is responsible for talking to the database. One object may be able to talk to multiple databases, or there may be a separate object for each one that can be plugged in as needed. Referential integrity is usually handled by the database or possibly the data access object.
>
>I hope this makes sense. I'm still trying to get a handle on this n-Tier stuff myself. In any case, there is no right or wrong here. If you think it is unlikely that you'll need to switch to another database, and you want to be able to access the database directly from multiple applications, then putting the validation in the database makes more sense. On the other hand, if you need the flexibility to use multiple back-ends, then n-Tier might be the way to go. Obviously, this approach is more complex, which is why many recommend one of the commercial frameworks.

Hi Joel,
Well I finally started reading about this n-Tier stuff. Now what you're saying makes sense. I'm one of those people who think that n-Tier is overkill in a lot of situations, and so far I've only dealt with those situations where it's overkill. Sometimes I feel like I'm being left behind by the rest of the FoxPro community, but I enjoy working with small time businesses too much to go on to something bigger.