This talk would have benefitted from having roughly half the slides, and more detail. Perhaps "4 or 5 things frequently done incorrectly while using Doctrine." In addition the speed of delivery was a bit fast, prompting some questions from attendees.
I would like to have seen a perspective other than "DDD is the only way that Doctrine makes sense" perspective. It does work in other development paradigms.
Good information, but the talk could use some polish
A great refresher to have someone else support domain design, entity vs. DTO, repository usage etc. Sometimes feel discourage promoting these through thicket of "its over kill" and "why bother if we have associative arrays". Consequently, begin to lose my way and get "infected" with bad practices. In this talk, Marco "re-calibrated" my brain a bit, and I learned some new techniques, such as deleting practices, ID generation, and use of query functions. Good balance between theoretical examples and code snippets. I wonder if some UML diagrams could have helped to further illustrate how doctrine fits within the architecture, but not strictly necessary.
I enjoyed the talk, as I have been looking at using Doctrine more and more, I have not yet found a use case for it myself but he made it very clear when it is appropriate to use it.
I concur with the previous comments that the talk felt a bit rushed, and the idea that "this is the only context in which you should use doctrine" felt very opinionated instead of informative.
I did enjoy the technical aspects of the talk but I also agree that perhaps limiting the use of acronyms, or at the very least including a brief explanation might have helped those less versed in the DDD lingo.
I personally felt that some of the advice offered in this talk wasn't very good. Following the advice really restricts how one could utilize an ORM in an effective way. For example, I don't agree that entities MUST contain behaviors, otherwise you shouldn't be using an ORM. We prefer to keep our models "stupid" and many of them contain little to no behavior. We still fully utilize doctrine as an ORM to manage those entities.
It was interesting to hear this talk from someone from the core Doctrine team. I took a lot of notes, and I think it was definitely worth attending. I agree that the speaker had an opinionated "this is the only way to use it" approach, but I think that was very much intentional.
Chase: as Chris said, this tone was indeed intentional.
Consider that I spent the last 5 years helping out folks that get trapped in ORM internal behaviors because of them mixing behavior with persistence, or because they were building an anemic domain with a "smart-ui" (which is an anti-pattern) on top of that.
This is the main reason why I designed this talk: helping people _before_ they build an unmanageable trap that leads to accusing the ORM (this happens _every_ time) of being slow or complex.
The entire philosophy of the talk revolves around keeping it simple and OO-based, and since it is an ORM (object mapper), if you don't do OO-based, then a Table-Data-Gateway approach is sufficient, for example.
We basically do the non-OO part for you, but if you also keep doing it that way (for example via getter-setter), then you are just making your life more complicated than it actually is needed to be :-D
Comments
Comments are closed.
Very quick speaker, used a lot of acronyms that required explanation. Got the feeling of 'my way is the only way'
This talk would have benefitted from having roughly half the slides, and more detail. Perhaps "4 or 5 things frequently done incorrectly while using Doctrine." In addition the speed of delivery was a bit fast, prompting some questions from attendees.
I would like to have seen a perspective other than "DDD is the only way that Doctrine makes sense" perspective. It does work in other development paradigms.
Good information, but the talk could use some polish
Very interesting presentation.
Please define acronyms.
A great refresher to have someone else support domain design, entity vs. DTO, repository usage etc. Sometimes feel discourage promoting these through thicket of "its over kill" and "why bother if we have associative arrays". Consequently, begin to lose my way and get "infected" with bad practices. In this talk, Marco "re-calibrated" my brain a bit, and I learned some new techniques, such as deleting practices, ID generation, and use of query functions. Good balance between theoretical examples and code snippets. I wonder if some UML diagrams could have helped to further illustrate how doctrine fits within the architecture, but not strictly necessary.
I enjoyed the talk, as I have been looking at using Doctrine more and more, I have not yet found a use case for it myself but he made it very clear when it is appropriate to use it.
I concur with the previous comments that the talk felt a bit rushed, and the idea that "this is the only context in which you should use doctrine" felt very opinionated instead of informative.
I did enjoy the technical aspects of the talk but I also agree that perhaps limiting the use of acronyms, or at the very least including a brief explanation might have helped those less versed in the DDD lingo.
I personally felt that some of the advice offered in this talk wasn't very good. Following the advice really restricts how one could utilize an ORM in an effective way. For example, I don't agree that entities MUST contain behaviors, otherwise you shouldn't be using an ORM. We prefer to keep our models "stupid" and many of them contain little to no behavior. We still fully utilize doctrine as an ORM to manage those entities.
It was interesting to hear this talk from someone from the core Doctrine team. I took a lot of notes, and I think it was definitely worth attending. I agree that the speaker had an opinionated "this is the only way to use it" approach, but I think that was very much intentional.
Chase: as Chris said, this tone was indeed intentional.
Consider that I spent the last 5 years helping out folks that get trapped in ORM internal behaviors because of them mixing behavior with persistence, or because they were building an anemic domain with a "smart-ui" (which is an anti-pattern) on top of that.
This is the main reason why I designed this talk: helping people _before_ they build an unmanageable trap that leads to accusing the ORM (this happens _every_ time) of being slow or complex.
The entire philosophy of the talk revolves around keeping it simple and OO-based, and since it is an ORM (object mapper), if you don't do OO-based, then a Table-Data-Gateway approach is sufficient, for example.
We basically do the non-OO part for you, but if you also keep doing it that way (for example via getter-setter), then you are just making your life more complicated than it actually is needed to be :-D