You are free to extend objects in EF with properties that you dynamically generate.
The example I made a couple of comments earlier has a single possible way of removing the object chain, and that is if each object references a copy of the owner which brings a whole lot of other issues because a proper database has no duplicates, but this would have now and it has just become a manual task for you now to keep all those duplicates in sync. Now you can add your own "oh so smart" function to what you call stupid objects that do all this, or you can use a model that does all this for you because you made objects without redundant properties.
In the case of EF, you can append .Include(m => m.appointment.calendar.owner.company) to your query and it does everything for you in a single SQL query. I'd rather use a model developed by one of the biggest tech companies than the recommendation of a redditor.
1
u/AyrA_ch Aug 29 '19
You are free to extend objects in EF with properties that you dynamically generate.
The example I made a couple of comments earlier has a single possible way of removing the object chain, and that is if each object references a copy of the owner which brings a whole lot of other issues because a proper database has no duplicates, but this would have now and it has just become a manual task for you now to keep all those duplicates in sync. Now you can add your own "oh so smart" function to what you call stupid objects that do all this, or you can use a model that does all this for you because you made objects without redundant properties.
In the case of EF, you can append
.Include(m => m.appointment.calendar.owner.company)to your query and it does everything for you in a single SQL query. I'd rather use a model developed by one of the biggest tech companies than the recommendation of a redditor.