That’s a fair point, but I thought you were trying to guarantee you had the correct type.

I know. I was re-emphasizing his point because it was confused with all the other stuff. The issues he describes are not addressed by removing code into a base class, it’s merely a different way of writing the same thing.

However none of this addresses what I think is your most important point, removing the redundancy of code. We could include the above code in each page where we need to access the cart, but that would create unnecessary maintenance overhead because we would need to update every instance of the code if anything changed.

Not if you do what Wyatt suggested and have it in a base page class and inherit from that.

@anon: Yes, it is a garden variety application layer error. But to end users, the server catching on fire and “there was an issue accessing the page” are the same thing and best avoided and/or caught during development.

well, thats not a crash then; its just your common garden error. a crash is something that brings the server down… nasty no?

where do you .net developers get your terminology from? m$? god?

the doctor

As far as loose typing is concerned, I don’t see how your second example really improves on the first. You’re still assuming that the ‘ShoppingCart’ will be the correct type. An exception will occur if for some reason an object has been stored in the session using the same key. The code you’ve written is essentially the same, even if the latter has been separated to a base class and exposes the cart via a property.

Perhaps a better example would be:

protected ShoppingCart Cart  
{  
   get  
   {
       ShoppingCart myCart = Session["ShoppingCart"] as ShoppingCart();
	
       if(myCart == null)  
       {  
           myCart = new ShoppingCart();

	   Session["ShoppingCart"] = myCart;
       }

       return myCart;
    }  
} 

This approach will always return a valid shopping cart without an exception, even if elsewhere ‘ShoppingCart’ has been used in the session for differently typed object. It’s a defensive approach that protects you against the unforseen and the loose typing of session.

However none of this addresses what I think is your most important point, removing the redundancy of code. We could include the above code in each page where we need to access the cart, but that would create unnecessary maintenance overhead because we would need to update every instance of the code if anything changed.

If you find you’re repeating code, find some way of isolating that code so it can be reused directly in all required circumstances. As you suggest, moving the code to a base class would be one method of achieving that.

> Errors can lead to crashes at best,

what do you mean by a crash though? how severe is it? the framework in question must be pretty fragile no; i mean a lack of encapsulation could cause so much damage?

i’m not having a go (well, just a wee bit, but thats not the point) but maybe you could enlighten us lot who develop without this ’state of the art’ framework from m$

best regards, the doctor.