I use a traditional MVC pattern for my web projects:
Controllers: handle use case scenarios steps (can call business logic in models or services)
I hit a wall with the model that prevents me from properly embracing object orientation. I got perhaps the wrong assumption that an entity should have only a single model.
For example, in my current web site project I have an 'image' entity. So I have a model to represent a row in the database 'image' table: I fetch the record to the model constructor, which nicely populate corresponding class properties. I can then use the instance in my code. Nice.
Problem is the other way around, when I must receive data from a form for database storage. The raw data from form needs quite some business processing, and involves coupling between data and logic for reuse, so a class is appropriate. Problem is that if I use the same model as above, the one for getting data FROM the database, things gets really ugly with lots of conditional in constructor.
Is one of the right thing to do, would simply create a separate model class for getting data TO the database, and not stay stuck with single model class for image ? What's the good practice in such case ?