Database Entity Object Model -- Loose vs Strict Representation? - php

Question

I'm trying to decide on this dilemma as I'm writing some PHP API's I'm working on. I'm trying my best to write some solid APIs without being a PHP veteran, by groping through the dark hoping to find some best practices. I'm also uncertain if I'm using the right terminologies, so please correct me.
I have some entities that store their data in a database, which I'm modeling in an object-oriented way. Should my models always strictly represent what's currently in the database, or not?
Loose Database Representation
The user can freely change the model's attributes, then later save whatever changes to the database.
The model does not always reflect what's in the database, because the user can change the model arbitrarily.
<?php
// Write a snippet
$snippet = (new Snippet)
->label("grapes")
->content("wine")
->save();
// Load a snippet
$snippet = (new Snippet)
->label("bananas")
->load();
// Update an existing snippet
$snippet
->content("potassium")
->save();
?>
Strict Database Representation
The user cannot freely change the model's attributes. Only getters are provided for the attributes (no setters).
The model is guaranteed to always represent what's in the database.
The only way to change the model, is to also change what's in the database.
<?php
// Write a snippet
$snippet = (new Snippet)->write("grapes", "wine");
// Load a snippet
$snippet = (new Snippet)->read("bananas");
// Update an existing snippet
$snippet->update("potassium");
?>
Which API style would you prefer to use?
I started with the loose model, and have started to wonder if the strict model is a better way to do things? Does the strict model's promise of integrity outweigh the loose model's flexibility?
I'm open to any thoughts, comments, pros/cons, alternatives, and ideas; I just want to do PHP right, and make a good API that other programmers find pleasing :)

Answer 1

Both examples remind me of the ActiveRecord pattern. ActiveRecord is when you endow your objects with CRUD methods - that is, they know how to create, read, update, and delete themselves from a data source.
Now, if I am understanding you correctly, you are wondering if it is better to be able to set a model's attributes, and then call CRUD methods on it, or call the CRUD methods directly, passing in arguments that set the attributes internally? In either case, it seems like both 'representations' are as loose or strict as the other. As far as a good API goes, I would say the 'loose' representation would be what most people expect.
Now, on to suggestions. There are two popular patterns for interacting with data sources. One is the ActiveRecord Pattern, and the other is the Repository Pattern. I've described briefly the ActiveRecord pattern. The Repository Pattern strips out data interaction responsibilities from the model, and puts it in a 'repository' class. This repository class is responsible for CRUD operations. There are many posts about the pros and cons of the ActiveRecord v. Repository Pattern out there, so you can look that up. I will say that the Repository Pattern is more widely accepted as being the 'better' one.
In reference to when you say, "The user can freely change the model's attributes, then later save whatever changes to the database.": Objects, in general, should protect their invariants. That is to say, you shouldn't allow their data to be set to an invalid state. An object should be constructed with the information it needs, and not provide setters unless it makes sense for the values in the object to be changed. And even then, you can often give a setter a better name then just setX(). ei: fillUp() instead of setFuel() on a car object.
I personally would design things with the repository pattern:
class SnippetRepository
void save(Snippet snippet) { ... }
void update(Snippet snippet) { ... }
boolean delete(Snippet snippet) { ... }
Snippet load(SnippetId id) { ... }
end
$snippet = (new Snippet)
->label("grapes")
->content("wine");
snippetRepository.save($snippet);
I hope that helps.