Class, DAL, and Performance

6 Comments

• If I understand this correctly when using "Lazy Loading" I would theoretically read the string from the database every time the said string property is read? Yes this would work for the example above, however what if I had another .aspx page in the same app that uses most or all of the properties in the same class. That is a trip to the DB for every property used. Or maybe I have "Lazy Loading" wrong.
  

• What about creating a base class for myclass that impliments only a subset of the properties that myClass does. Example:
  
  
  
  MyBaseClass:
  
  FirstName
  
  LastName
  
  DriversLicence
  
  ID
  
  
  
  
  
  MyClass (Inherits MyBaseClass):
  
  Middle Name
  
  Social
  
  Address
  
  Phone.
  
  
  
  So for the smaller use pages, you could create a instance of MyBaseClass, populate the 5 or so properties and then throw it up to the session or wherever. When you need the extended property set, you could instantiate MyClass and perhaps have the constructer accept a copy of MyBaseClass (to populate the fields you already have) and fill the rest of MyClass's properties from the DB.
  
  
  
  Yea?
  
  
  
  -nathan
  
  
  
  
  
  

• Nathan,
  
  Yes that works too.
  
  
  
  You couls create a MyClass and a MyClass Simple.
  
  
  
  Kevin
  

• To make sure I got this right.
  
  
  
  So by using inheritance I would a have a class for each aspx page depending on what properties are used on the page? (some classes could be used for multiple pages of course) All classes would derive from the base class (which contains highly used attributes only).
  
  
  
  In order to keep database calls specialized, I would have to create a different class for each webform. And create a method in my DAL for each one of these classes.
  

• You don't have to hit the database every time a property is accessed. There are quite a few ways to implement the "lazy-load" pattern, and it really depends on your situation how you should go about it. A basic implementation would be to load any common properties in the constructor - the properties always (or almost always) accessed. Then, use a private boolean variable to track whether or not the "extended" properties have been loaded yet - ie, every property other than those loaded in the constructor. In each of the getters for the extended properties, check the private variable. If it's false, call some method to load the extended properties and set the private variable to true. Basically, you wind-up with a lightly-loaded class upon initialization which can fullfill the most basic and common property requests. Upon another class accessing a less-used ("extended") property, you make the additional trip to the database to load all those other properties. You only make that trip once, though, because you're tracking whether or not you've already done it using that private variable.
  
  
  
  Good luck.
  

• Hmmm, I don't quite agree with everyone so far. Yes, lazy loading is a way forward, and I think the type of implementation would be called a ghost object - as opposed to the more frequent lazy load which only loads a related object when it's accessed - ie you're talking about a string which is just a property (not even a value object in this case). Now, consider where the pain is in this - making the network round trip to the database usually - so since you're going to HAVE to make the call to the database anyway, its usually not a problem to pull back the rest of the table data in that trip. Yes, if you were retrieving several thousand of the items, then bandwidth may start to become an issue, but otherwise since you're their, get it all. Also, to turn it into a ghost object smells a bit like premature optimization, which just complicates your code... and YAGNI ;) [Also, ideally your DAL (O/R Mapper) would be caching retrieved objects so the next request for this object would not have to hit the db].
  
  
  
  i/Noodle.