Rubbish. The interpretation of Soc/SRP which I use are the ones provided by Robert C. Martin. In his articles http://blog.8thlight.com/uncle-bob/2014/05/01/Design-Damage.html he said this:
How do you separate concerns? You separate behaviors that change at different times for different reasons. Things that change together you keep together. Things that change apart you keep apart.
GUIs change at a very different rate, and for very different reasons, than business rules. Database schemas change for very different reasons, and at very different rates than business rules. Keeping these concerns (GUI, business rules, database) separate is good design.
In his article http://blog.8thlight.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html he said this:
This is the reason we do not put SQL in JSPs. This is the reason we do not generate HTML in the modules that compute results. This is the reason that business rules should not know the database schema. This is the reason we separate concerns.
“Gather together the things that change for the same reasons. Separate those things that change for different reasons.”
If you think about this you’ll realize that this is just another way to define cohesion and coupling. We want to increase the cohesion between things that change for the same reasons, and we want to decrease the coupling between those things that change for different reasons.
He says quite clearly in those articles that it would be good design to separate out the GUI logic, the business logic, and the database logic. This description matches the 3-Tier Architecture ( http://www.tonymarston.net/php-mysql/3-tier-architecture.html ) which is precisely what I have implemented in my framework ( http://www.tonymarston.net/php-mysql/infrastructure.html ).
If you don’t like Robert C. Martin’s interpretation of SRP - and remember that he actually invented the term - then I suggest that you take it up with him and stop wasting my time.