Recording Venue:
Guest(s): Michael Plöd
Host(s): Arno
In this episode, Michael Plöd is interviewed about Object-Relational Mapping technology. He talks about the common concepts, compares the range of different tools that go by this name, and goes into the design and architectural consequences of using an OR mapper.
When I read the title for this episode I thought it would be great. SE-Radio always presents valuable information given by the real experts so I thought we would have a discussion about the concepts behind ORM or maybe its evolution and interesting alternatives like gemstone’s Ruby and Smalltalk products. Turns out that the episode presents merely superficial (even inaccurate) information on how Java ORM frameworks work and some random bits about .Net.
I understand that there is demand for such but I’d ask you guys to at least place those in a separate feed, category, tag or something.
Keep the good work.
You are right, this is an introductory episode, and it is somewhat Java focused.
I agree that an episode on the underlying concepts and the history of O/R mappers would be interesting, and I can see how the title could lead you to expect this episode to be just that – sorry about that.
Thanks for the feedback and for taking the time to make the good suggestions!
– Arno Haase
Basic, but nice one, nevertheless! I just wrote a blog post joining in on your thoughts on DAO Pattern: http://www.olivergierke.de/wordpress/2009/01/se-radio-episode-121-or-mappers/
Regards,
Ollie
Hi,
this was a good introductory episode. I’ve listened to every SE radio episode so far and think its one of the best podcasts out there. Keep up the great work.
I would love to hear a more detailed discussion about the Lazy Loading topic and how to create a modular data model in general (maybe in a future episode). Michael argued that a single eager load can basically pull the whole database into memory. To me this sounds like a too entagled domain model (see Eric Evans aggregate root discussion in DDD). I don’t want to say Lazy Loading is always bad but in my opinion it can hide dependencies which are not revealed until the objects cross VM or service boundaries.
Thanks a lot,
Sebastian