The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

benethridge (4) [Avatar] Offline
#1
Hi, Chris.

Reading POJOs in Action, I have a general java design question.

First off, the way you have designed the Food To Go using the domain objects and the repository objects makes sense to me.

However, I got to thinking about the use of light-weight DTO's (or simple JavaBeans or whatever you want to call them) vs the relatively heavy-weight domain objects you show.

The advantage of the DTO model is that, by convention and by design, it contains no behavior (i.e. no business logic methods - just simple getter/setters), i.e. it is light-weight.

The disadvantage is that it forms an extra code maintenance layer (simple, but tedious and boring to maintain). If your database schema is non-changing (say, in stable production), this is often no big deal, but if you're in active development and the schema is changing all the time, the DTO maintenance is a real pain.

Now, keeping that in mind, imagine that the Food To Go business really takes off, processing thousands of orders a day, and goes international, such that there are now thousands of Restaurants and millions of Orders in the persistence layer.

Further imagine that the Food To Go app needs to be functionally enhanced, such that, say, the Order class functionally needs 30-50 conceptual business methods, and each of those methods contains a few pages of necessary business logic (or needs to call other objects/methods that encapsulate them - i.e. the logic has to live SOMEWHERE).

Won't the size of the relatively heavy-weight Order object (and/or its contained or associated children) now bog the app down performance-wise, as potentially thousands of heavy-weight Orders are retrieved from the repository?

From a design point of view, would it not make sense, given the above, to accept the maintenance hit of a "feather-weight" OrderDTO that is then "injected" from the light-weight OrderRepository (light-weight because it uses the DTOs) into the heavier-weight Order object, once the app knows it need the Order object's heavy-weight behavior?

...or is Java 1.5 intelligent enough to "lazily-instantiate" (for lack of a better word on my part) the heavy-weight object's behavior (i.e. methods), in which case the DTOs are unnecessary?

Ben
ceracm (113) [Avatar] Online
#2
Re: Light-weight vs heavy-weight POJOs and scalability
Ben,

The short answer to your question is that the "weight" of an object is independent of the number of methods it has. The cost of retrieving an object from the database is proportional to the amount of data it concerns. Roughly speaking each non-collection field corresponds to a column in the database. The methods are completely within the JVM.

Chris
benethridge (4) [Avatar] Offline
#3
Re: Light-weight vs heavy-weight POJOs and scalability
Thanks, Chris.

If I'm understanding this article correctly, it supports what you are saying. See "JIT Compiled Code" in "5.2.2 Classes":

http://java.sun.com/docs/books/performance/1st_edition/html/JPRAMFootprint.fm.html

The JIT compiler is a better way of saying what I was calling "lazy instantiation" of the method. Since this JIT compilation takes place at the class level, instead of the object level, it appears that one can instantiate thousands of object with no overhead, as far as the methods are concerned.

Of course, the act of instantiating thousands of objects has its own performance implications, as this article shows:

http://www.javaworld.com/javaworld/jw-07-2003/jw-0725-designpatterns.html

...but that is beyond the scope of my original question.

Thanks, again.

Ben