Comments on: Tips for ORM Data Access

By: arnshea

arnshea — Mon, 16 Nov 2009 23:00:09 +0000

Another approach I’ve tended to favor over the past few years is the following:

Don’t use ORMs.

Applying the ER model will make you a better OO designer.

Modeling it yourself will encourage you to be sparing; you’ll gravitate towards 3rd normal form where appropriate.

Modeling it yourself will reinforce your understanding of the underlying problem domain which will result in a leaner OO model.

Visual DB design tools = good (no point futzing around with DDL all day).

Object to Relational mappers = bad. They leak and they’re brittle. They’re an overapplication of the OO metaphor.

SQL is good. SQL is easy. Specifying the what is easier than specifying the how.

By: Steve Py

Steve Py — Sun, 15 Nov 2009 03:07:08 +0000

I don’t agree with avoiding lazy-loading. You can have your cake and eat it too by exposing explicit graph loads via things like Fetch.

The problem with DTOs and the like is type transference where once you flatten an object you need to manage when that flattened entity needs to be re-retrieved as a “real” entity.

For example I may pull a list of lazy-loaded objects, then when I go to the details page I may very well decide to fetch all “child” objects that make up the composition at once if I know I’m probably going to be hitting most of the data anyways. I don’t really want to be dealing with different objects that represent different views of the same data.

As for situations where foo.name = a.b.c.d{.name} I don’t think there’s anything wrong with exposing commonly used “optimizations”. I.e. foo.name = a.dname, where dname = a.b.c.d.name. Nothing more than a simple assertion test is required to assert that a.dname doesn’t start to mean something different to a.b.c.d.name.

By: Dimitris

Dimitris — Sat, 14 Nov 2009 13:18:02 +0000

Excuse me for I am a java guy jumping into a .net discussion.
DTOs are an anti-pattern and should be discouraged. Use proper models for the straight cases and/or projections for the advanced cases.

http://anirudhvyas.com/root/2008/04/19/abuses-of-dto-pattern-in-java-world/

By: Mark

Mark — Sat, 14 Nov 2009 02:47:05 +0000

@Scott Parker
You don’t need DTOs. They were for EJB1/2. It was for limiting network hits. You need something like a ViewModel or projection as he said. Or whatever you want to call it (a Report object?). Anyway, what it is is a READONLY object that contains attributes of one or more Domain/Entity objects. For [N]Hibernate you would do something like “select new PersonViewModel(p.firstName, p.lastName, a.city, ph.phoneNumber) from Person as p, Address as a, Phone as ph
where a.person = p
and a.primary = true
and ph.person = p
and ph.primary = true

By: Jarod Ferguson

Jarod Ferguson — Sat, 14 Nov 2009 00:18:49 +0000

@scott I responded with a new post here – http://elegantcode.com/2009/11/13/dtos-ddd-the-anemic-domain-model/

By: Elegant Code » DTO’s, DDD & The Anemic Domain Model

Elegant Code » DTO’s, DDD & The Anemic Domain Model — Sat, 14 Nov 2009 00:17:49 +0000

[...] had a comment on my last post Tips for ORM Data Access which i would like like to address with this blog post. I have been trying to wrap my head around [...]

By: Jason Grundy

Jason Grundy — Fri, 13 Nov 2009 22:29:32 +0000

Great post Jarod. Obviously this is something that we’ve talked about a great deal in the past…and in the future I’m sure

A few observations specifically on NHibernate:
1) For tracing of SQL statements NHibernate has excellent log4net integration.
2) Projections can often be used instead of Stored Procedures and will often generate very efficient SQL.

By: Scott Parker

Scott Parker — Fri, 13 Nov 2009 21:47:49 +0000

Wow! This article found me at just the right time. Funny how that works.

I have been trying to wrap my head around the role of the DTO in DDD. My reading of Fowler and Evans seems to indicate that you ought to have your domain objects themselves mapping into your database, rather than dedicated function-less DTOs. Relying on DTOs that are then handled by Services seems to lead to what Fowler calls The Anemic Domain Anti-Pattern: http://martinfowler.com/bliki/AnemicDomainModel.html

However, I have a tough time writing Entity classes that operate in that manner that don’t end up rather painful to change and extend.

Since you recommend the practice of using DTOs, do you have any thoughts on the subject?

Thanks!

By: Jarod Ferguson

Jarod Ferguson — Fri, 13 Nov 2009 20:29:29 +0000

@ng
CQS is great, though not always applicable in the context in which I have heard Greg and Udi speak about it, which is usually large scale distributed messaging.

I think the common concept here, which is not new to cqs, is that I may have one model that I use for complex domain logic, saving & updating, and another simplified one for reading. (or even seperate tiers)

“Aggregates cannot call into other aggregates children”
Yes, only for updates/inserts. If your doing CQS they would not be the same anyway right

By: Joe

Joe — Fri, 13 Nov 2009 10:28:59 +0000

You should fix your apostrophe’s, it will make the article sound more authorittative.