@heluecht The problem of setting and storing arbitrary values is that we don't have any control nor visibility on it. By using meaningfully named methods affecting a fixed list of private class variables, we have complete control over what any part of the code interact with the Entity. No code can set dismissed to 2 as it would be possible with a setDismissed(int $dismiss) method for example.

It's even worse with arbitrary array. update(array $fields) doesn't tell you what value type are expected, what values are required, etc... Worse, by tightly coupling the object and the persistence layer (the database), it makes it harder to write unit tests for our Entity.

So we split it. On one hand, the Entity that describes the exact data it needs and the only approved operations on it, with absolutely no care how it's going to be stored. Memory, key-value store, NoSQL database, it doesn't matter to the Entity.

On the other hand, we have the Repository, which knows how to persist and retrieve Entity object to the persistence layer of choice (here, MySQL only for now), but no more so that we keep the hard-to-test code surface as small as possible.