Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Is domain model object passing between layers overhead?

 
Thihara Neranjya
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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....
 
Karthik Shiraly
Bartender
Posts: 1210
25
Android C++ Java Linux PHP Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If all 3 layers are deployed in the same application server JVM, then I don't understand what is the overhead, since it's just a reference that is being passed. If the issue is updating entire row vs updating a single column, it should be handled in the DAO using an update query or dynamic update to update only changed columns.

If on the other hand they are deployed in a distributed architecture, then there's a case for using lightweight transfer objects to optimize network traffic, provided network traffic has been measured and proven to be a bottleneck.
Even in this situation, I think the transfer object should encapsulate details of the ID and not reveal its fields as method arguments.
A method like "updateMyObjectState(int ID, boolean newValue)" knows too much information about internal details of the object (that ID is currently an int; what if it later changes to long or a composite key? More components are likely to get impacted whenever such details are unveiled) vs a method like "updateMyObjectState(MyObjectTO changed)".

Such "code review optimizations" are easy to find and tough to argue against, but these seemingly minor changes can severely restrict flexibility of the system to accommodate requirements later on.
If there's no confirmed bottleneck, don't optimize it.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic