Is domain model object passing between layers overhead?

Question

I am working on a project that uses hibernate and spring. Hibernate is encapsulated in a DAO layer and the DAO layer has corresponding service layer as well, theres also the controllers that is mapped for requests and JSP pages. I was told not to pass objects between these layers (Controllers <-> Service <-> DAO) as it is performance overhead. One particular instance was when I needed to update a boolean value in a domain object (ORM class), I wrote a method that passed the domain object between Service layer and DAO layer, and I was told to pass the object ID and the particular boolean value only and to write separate methods in the layers for that. Is this right? I feel doing so will invalidate many advantages of using an ORM tool (Hibernate). Am I wrong to think this? Any advice and insights will be useful....

Answer 1

You're 100% right. That's terrible advice. Pass the objects around. It's exactly what Hibernate is designed for, and "performance overhead" for normal passing of objects is just crazy. Unless there's something about the app that you don't know, be wary of advice from the person that told you that.

Answer 2

As with most architecture issues, there is a tradeoff to be made here.

For applications that don't expect to use a service-orientated architecture (e.g. a self-contained website with backing database, a single internal business application), it's much better to have your domain model exposed at all layers of the application. This ensures that you don't violate the DRY (Don't Repeat Yourself) principle, and you don't have to do lots of refactoring every time you add a new property to your domain model. You can also use a framework like the NHibernate Validator to define all of your validation once, and use that validation for both the data layer and the web layer.

For larger applications that contain many separate services (e.g. large suites of internal business applications), it's desirable to separate the ORM from the interface of the service. This will allow you to make changes to your data access models without changing the interface of the service (and vice versa), which is extremely valuable when many other services depend on your interface remaining stable.

However, the situation you describe (using methods to change specific properties) doesn't seem to match either of these scenarios: it's generally a bad idea to follow the pattern you've described as it makes tracing execution paths and refactoring very difficult (and can lead to spaghetti code). The only possible useage I can think of is if your data models are very large (5k XML blobs, etc) and sending them across the service layer would generate large amounts of traffic. (NB: C# objects are much smaller than 5k when serialised correctly!)

I would recommend that you do pass the entire data access model up to the web layer.

Answer 3

premature optimization is the root of all evil

Even in High Frequency Trading, where 50 nanoseconds matter, you do what is right first, and then you optimize if needed. You'd be surprised what modern compilers / network bandwidth can do.

To answer your question more directly => pass those Objects around and don't think about the performance. You will, if you need to later, but it is highly unlikely it is going to be caused by passing Objects around.