My interview with DotNetRocks! is now online!

11 Comments

• About frickin' time they interviewed you! Good - can't wait to check it out.
  

• Good interview! I'm a bit confused on one of your answers about lazy-loading though...
  
  Why can't lazy-loading use the repository to get its data?
  

• Mike: it can only use a repository if the collection exposing property calls into the repository.
  
  Take for example Customer.Orders. When I do:
  Orders myOrders = myCustomer.Orders;
  if(myOrders.Count>0)
  {
  myOrder = myOrders[0];
  }
  (bogus code, but you get the idea ;))
  
  In the example, the Orders property is a property which exposes a collection which is lazy loaded. Typically, an o/r mapper will make sure that this is done automatically, so if you touch that property, it loads the data.
  
  However, Order is an aggregate root. So typically, it should use the Order repository to fetch the orders for that customer, not a query formulated by the o/r mapper based on the access of the property.
  
  To implement that, you effectively have to throw away the mechanism that's introduced by the o/r mapper to make lazy loading possible, hence the bypassing.
  

• "So typically, it should use the Order repository to fetch the orders for that customer, not a query formulated by the o/r mapper based on the access of the property."
  
  I guess thats my question. Why can't the call from the Orders collection use the Order repository with something like:
  Me.Orders.Fill( OrdersRepository.GetOrdersForCustomer(Me.Customer_ID) )
  
  ?
  

• Cool Frans! It was a lot fun finally hearing you with the guys :-)
  
  When can you do this talk for the usergroup? This fall maybe?
  
  

• Mike: Sure, but that circumvents the lazy loading functionality provided by an o/r mapper and effectively makes YOU the one writing the lazy loading code. :)
  
  take for example a POCO using o/r mapper: it will likely replace your List collection with their own collection and override the Orders property with their own code in a dyn. proxy class which will make sure the lazy loading code of the o/r mapper is performed when the property is read. So working around this is of course possible but you then actually don't have the lazy loading ofthe o/r mapper but you've to build it yourself. This is kind of tricky though: for example you only want to call into the repository the first time, the second time you just want to return the entities you read the previous time instead. So you have to have flags as well which track this. :)
  
  Dennis: Thanks :) What kind of talk did you have in mind exactly? (as this was an interview ;))
  

• You could let the O/R Mapper know about the repositories, of course. It might even be a nice type of plugability point. Hmmm. Something to think about. :-)
  
  It would not really reduce the work of the O/R Framework because behind that repository, in all likelyhood you would find the O/R Mapper again...but it would mean that it would be easier to integrate the mapper with a popular architecture style. Again hmmmm. :-) Perhaps the weekend is saved then! ;-)
  

• The nervousness at the beginning resulted in a lot of uhm's but it got a lot better later on ;). Was fun to hear you talk about ORM and software development in general !
  

• Looking forward to listening to it. I was wondering where the LLBLGen love was in their recent ORM focus.
  

• Really good interview Frans.
  
  I always knew you were a smart guy -- but until I heard this interview I didn't realise you were such a level-headed and friendly guy with a good sense of humour.
  
  It's great hearing someone interviewed who you've only read before -- it reveals their personality better than just writing.
  
  So thanks for taking part Frans.
  
  best of luck.
  
  lb
  
  

• Thanks lb and others for the great comments! :)