I was hoping someone might be able to help with an overall application design question... here goes...
I'm writing an e-commerce application from scratch. The backend is a PostgreSQL schema that I spent some time putting together. It's fairly elaborate yet very flexible as to the kind of products that can be stored in the DB. There is a lot of business logic already in the DB, in terms of functions that I wrote coupled with triggers to make sure the data integrity is preserved.
Now, what's tripping me up is exactly how "heavy" or "light" I should make the corresponding PHP classes. I see two main approaches:
In the past, I wrote most classes with Get and Set methods that interacted directly with the database itself - every method consisted of a SELECT or UPDATE query. This kept the code for each class reasonably trim, and the amount of data stored in each object's property was small.
I also considered the approach of storing data in the object itself. One method would load data from the DB into the properties of the class and then the Get methods would pull from those properties instead of directly from the DB. The Set methods would set the properties of class, and then a method would be called to "publish" the data from the class and run an update query against the database.
Has anyone else pondered this difference in design approaches? Should classes that utilize a DB capable of holding its own business logic be lightweight as per example 1? Should classes for a lightweight database that doesn't have foreign key support, triggers, stored procedures etc be "heavyweight" since the business rules can't be stored in the DB?
I'd really appreciate any insight anyone might have into this question... thanks very much!
