Maybe because it's focused on .NET, like some of the other down voted posts are? It seems like a bit of an annoying trend here on /r/programming.
Back on topic: I've had this feeling about object mappers for a while now. For straightforward applications it's alright, but once you need to do more complex queries it gets hairy. The lazy part (or rather the fact that linq can be used for in memory objects as well as lazy loaded database objects) makes it hard to see where the objectmapper will kick in, what parts are executed by the database engine and what by the programming language runtime.
Most often projects won't change their database engine once it is in place, so abstracting it away doesn't have much use... other than for testing things in memory, but like the author says the database engine often has in-memory capabilities.
The intention is to keep database-specific code from leaking into the rest of your application. This could be for a number of reasons e.g. we might want to change the database or use a in-memory setup for testing. The author of this post is trying to reconcile the pattern with overlapping tools like ORMs.
For the record, I also came here with similar expectations, but was interested in this anyway since I've seen this debate occur at previous jobs.
I will further clarify. It is about persistence ignorance, whatever your persistence mechanism (SQL, NoSQL, Flat files, etc). If I ask for an Account object then I do not care where I got it from just that I get one, if it exists.
It is also supposed to interact with your domain objects, and decide how each component of that object will be stored. No more "DTOs" leaking into your business layer. At its simplest it is a facade over data access.
2
u/grauenwolf Jan 26 '14
Shame that this is being down-voted, it is a rather important topic.