Data Transfer Objects and Lazy Load

Data Transfer Objects and Lazy Load

• Tryst

  These are pretty othogonal concepts. I think the issue you have is that you're applying both concepts to the same data. A better way of looking at this might be that if you're doing a smart client Order application you might download all the orders for a customer immediately but lazy-load the order lines only when the user needs them. Whether this makes sense or not will depend on how much it reduces data transfer costs and how likely the user is to request order lines. For example if any particular customer only has a few orders and most users will eventually ask for the order lines for all the orders then lazy loading doesn't make much sense - you might as well load the lines when you request the orders. On the other hand if a typical customer has hundreds of orders and the most common use-case is to search through the list of orders and look at the details of one or two of them then then lazy loading makes sense.

  You also have to consider how quickly the data gets out of date. If the data changes frequently then you're probably wasting time downloading a lot of data because by the time the user sees it, it is likely to be out of date.

  The other factor to consider is that smart client apps sometimes need an off-line story. If you want the user to be able to work with orders when not connected to the host, you obvioulsy have to download everything.

  
  

• Tilfried Weissenberger

  The intent of the DTO is not to replace multiple calls with a single call, but rather multiple parameters of a single call with a single object. The idea of creating an API that has coarse-grained calls - those that do the work of multiple other calls, is different and makes a lot of sense for calls that go across the network.

  You're understanding of lazy loading is correct but it appears that you are using it for the wrong problem. There are some O/R mappers that allow you to define different lazy behavior on load in different cases. NHibernate is one that doesn't (yet ). Regardless, for just READ behavior, I'm not sure that business objects are the best solution - sometimes a datatable is just fine. Once you need to go update data, then absolutely, use your business objects for that. It will also make it clearer when you should use lazy loading and when not to.

  Let me know if that helps.

   

  
  
  

• Ms_user

  It sounds as though you have not explored the idea of 'caching' data, Roger hints as this when talking about how quickly data gets out of date – ‘stale data’. This is different from lazy loading data is the idea of removing expensive repetitive calls to retrieve\calculate data by 'caching' the result.

  Now from my experience to utilise caching well you have understand how your data is going to be used - some data is read only (reference data), some data changes infrequently and some data changes frequently - the volatility of the data. This might seems simple but it can get rather complicated when you start to analysis business process to determine which data can be cached.

  Currently we use data caching quite alot to reduce load on the database servers, the business logic layer of our application caches all types of volatile data, the data access layer utilises Sql Server 2005 notification services to alert of data changes which are propagated to the business logic layer using events (observation pattern). Now we don't cache all data only data we have determined helps the performance\scalability of the system.

  HTH

  Ollie Riches

   

   

  
  
  
• Data Transfer Objects and Lazy Load