Return to Answer

First of all, merely citing someone's article on the Internet does not constitute sufficient justification for changing a practice. You have to weigh the pros and cons, and make up your own mind.

Note that the author of the article you cited hates ORM's. He follows a strict principle of encapsulating code with its data, which is sort of the foundational principle of object-orientation. He strongly dislikes ORM because it strips classes of their intelligence, and he's not wrong about that.

In his ORM hate article, he writes (more or less) that classes should be responsible for saving themselves to the database, a practice that violates a principle called "persistence ignorance." Persistence ignorance simply means that classes shouldn't know anything about their database overlord, and it's difficult to achieve this in any realistic manner with ORM's. He gets around the persistence ignorance problem by using interfaces, making his data ignorant of its underlying implementation.

To be fair, I write code that looks a lot like his under the hood, albeit a bit more streamlined than his (Java has a reputation for being very verbose). After wrestling with Entity Framework for awhile, I began using Dapper and writing SQL queries instead. I get better performance, less complexity and finer targeting of the database.

The class that implements your so-called "data transfer object" is a nice place to put this code; all you have to do is hand it an IdbConnection object, and the class has all it needs to read from and persist itself to the database.

I guess my question is, why does this have to be an either/or choice? If you need something from the database that requires a DTO, then use a DTO. If you want what you're calling a "domain object," then use that instead.

First of all, merely citing someone's article on the Internet does not constitute sufficient justification for changing a practice. You have to weigh the pros and cons, and make up your own mind.

Note that the author of the article you cited hates ORM's. He follows a strict principle of encapsulating code with its data, which is sort of the foundational principle of object-orientation. He strongly dislikes ORM because it strips classes of their intelligence, and he's not wrong about that.

In his ORM hate article, he writes (more or less) that classes should be responsible for saving themselves to the database, a practice that violates a principle called "persistence ignorance." Persistence ignorance simply means that classes shouldn't know anything about their database overlord, and it's difficult to achieve this in any realistic manner with ORM's. He gets around the persistence ignorance problem by using interfaces, making his data ignorant of its underlying implementation.

To be fair, I write code that looks a lot like his under the hood, albeit a bit more streamlined than his (Java has a reputation for being very verbose, and I don't bother with the DTO interfaces). After wrestling with Entity Framework for awhile, I began using Dapper and writing SQL queries instead. I get better performance, less complexity and finer targeting of the database.

The class that implements your so-called "data transfer object" is a nice place to put this code; all you have to do is hand it an IdbConnection object, and the class has all it needs to read from and persist itself to the database.

I guess my question is, why does this have to be an either/or choice? If you need something from the database that requires a DTO, then use a DTO. If you want what you're calling a "domain object," then use that instead.

First of all, merely citing someone's article on the Internet does not constitute sufficient justification for changing a practice. You have to weigh the pros and cons, and make up your own mind.

Note that the author of the article you cited hates ORM's. He follows a strict principle of encapsulating code with its data, which is sort of the foundational principle of object-orientation. He strongly dislikes ORM because it strips classes of their intelligence, and he's not wrong about that.

In his ORM hate article, he writes (more or less) that classes should be responsible for saving themselves to the database, a practice that violates a principle called "persistence ignorance." Persistence ignorance simply means that classes shouldn't know anything about their database overlord, and it's difficult to achieve this in any realistic manner with ORM's. He gets around the persistence ignorance problem by using interfaces, making his data ignorant of its underlying implementation.

To be fair, I write code that looks a lot like his under the hood, albeit a bit more streamlined than his (Java has a reputation for being very verbose). After wrestling with Entity Framework for awhile, I began using Dapper and writing SQL queries instead. I get better performance, less complexity and finer targeting of the database.

The class that implements your so-called "data transfer object" is a nice place to put this code; all you have to do is hand it an IdbConnection object, and the class has all it needs to read from and persist itself to the database.

I guess my question is, why does this have to be an either/or choice? If you need something from the database that requires a DTO, then use a DTO. If you want what you're calling a "domain object," then use that instead.

First of all, merely citing someone's article on the Internet does not constitute sufficient justification for changing a practice. You have to weigh the pros and cons, and make up your own mind.

Note that the author of the article you cited hates ORM's. He follows a strict principle of encapsulating code with its data, which is sort of the foundational principle of object-orientation. He strongly dislikes ORM because it strips classes of their intelligence, and he's not wrong about that.

In his ORM hate article, he writes (more or less) that classes should be responsible for saving themselves to the database, a practice that violates a principle called "persistence ignorance." Persistence ignorance simply means that classes shouldn't know anything about their database overlord, and it's difficult to achieve this in any realistic manner with ORM's. He gets around the persistence ignorance problem by using interfaces, making his data ignorant of its underlying implementation.

To be fair, I write code that looks a lot like his under the hood, albeit a bit more streamlined than his (Java has a reputation for being very verbose). After wrestling with Entity Framework for awhile, I began using Dapper and writing SQL queries instead. I get better performance, less complexity and finer targeting of the database.

The class that implements your so-called "data transfer object" is a nice place to put this code; all you have to do is hand it an IdbConnection object, and the class has all it needs to read from and persist itself to the database.

I guess my question is, why does this have to be an either/or choice? If you need something from the database that requires a DTO, then use a DTO. If you want what you're calling a "domain object," then use that instead.

First of all, merely citing someone's article on the Internet does not constitute sufficient justification for changing a practice. You have to weight the pros and cons, and make up your own mind.

Note that the author of the article you cited hates ORM's. He follows a strict principle of encapsulating code with its data, which is sort of the foundational principle of object-orientation. He strongly dislikes ORM because it strips classes of their intelligence, and he's not wrong about that.

In his ORM hate article, he writes (more or less) that classes should be responsible for saving themselves to the database, a practice that violates a principle called "persistence ignorance." Persistence ignorance simply means that classes shouldn't know anything about their database overlord, and it's difficult to achieve this in any realistic manner with ORM's. He gets around the persistence ignorance problem by using interfaces, making his data ignorant of its underlying implementation.

To be fair, I write code that looks a lot like his under the hood, albeit a bit more streamlined than his (Java has a reputation for being very verbose). After wrestling with Entity Framework for awhile, I began using Dapper and writing SQL queries instead. I get better performance, less complexity and finer targeting of the database.

The class that implements your so-called "data transfer object" is a nice place to put this code; all you have to do is hand it an IdbConnection object, and the class has all it needs to read from and persist itself to the database.

I guess my question is, why does this have to be an either/or choice? If you need something from the database that requires a DTO, then use a DTO. If you want what you're calling a "domain object," then use that instead.

First of all, merely citing someone's article on the Internet does not constitute sufficient justification for changing a practice. You have to weigh the pros and cons, and make up your own mind.

Note that the author of the article you cited hates ORM's. He follows a strict principle of encapsulating code with its data, which is sort of the foundational principle of object-orientation. He strongly dislikes ORM because it strips classes of their intelligence, and he's not wrong about that.

In his ORM hate article, he writes (more or less) that classes should be responsible for saving themselves to the database, a practice that violates a principle called "persistence ignorance." Persistence ignorance simply means that classes shouldn't know anything about their database overlord, and it's difficult to achieve this in any realistic manner with ORM's. He gets around the persistence ignorance problem by using interfaces, making his data ignorant of its underlying implementation.

To be fair, I write code that looks a lot like his under the hood, albeit a bit more streamlined than his (Java has a reputation for being very verbose). After wrestling with Entity Framework for awhile, I began using Dapper and writing SQL queries instead. I get better performance, less complexity and finer targeting of the database.

The class that implements your so-called "data transfer object" is a nice place to put this code; all you have to do is hand it an IdbConnection object, and the class has all it needs to read from and persist itself to the database.

I guess my question is, why does this have to be an either/or choice? If you need something from the database that requires a DTO, then use a DTO. If you want what you're calling a "domain object," then use that instead.