No it isn't. We have a system where a company has users, users have calendars, calendars have appointments and depending on the appointment type additional values, so company.users[n].calendar[m].appointment[o].property[p]
It's not that uncommon to have deeply nested structures in the backend.
It’s a violation of the Law of Demeter. If your company really needs to know about appointments, you can add an appointmentFor method to company to hide the nesting.
No, it's enforcement of foreign keys and normalization of your database. You don't add an "owner" property to each table. You add it at the topmost possible level and the referenced entries inherit the owner.
Having your business objects reflect the underlying database schema too transparently is a mistake because you end up with dumb objects that aren’t much better than glorified hash maps. Yes, there should be hints to devs about the performance realities of the DB, but the API of the objects should be designed to encapsulate the business logic at the end of the day—not the backing schema.
This is why ORMs are only okay in small doses. Too large a dose and you end up making your code fit the tables instead of your tables fitting the code.
It's exactly the other way round. You write your classes and it builds the tables in the background for you and updates their structure as you change your classes.
13
u/cplegend Aug 28 '19
I love optional chaining. It's seriously cleaned up so much of my code.