> Not necessarily at all. It takes a profound lack of imagination to believe that's the only way to handle business logic ++ persistence. It is a stretch to sa

> Not necessarily at all. It takes a profound lack of imagination to believe that's the only way to handle business logic ++ persistence. It is a stretch to say that there is an idiomatic way to avoid classes as domain objects in most languages. Imagine in $classBasedLanguage you used static functions and key/value arrays..do you think that's a good idea? That's all I was saying. > Furthermore, freeing yourself from the constraints of the persistence side.. If you're making an ERD, a lot of what you're doing is deciding entity relationships and just naming your data. None of that is impossible with classes.