Moving House

I've moved this blog over to WordPress. All the posts are also there, and those of you subscribed through feedburner shouldn't notice if I manage to get the transfer right.

My new address is http://seesharper.wordpress.com

When are there just too many generics?

Generics are a pretty cool language feature. They provide type safety and felxible reuse at the same time, and I reckon that's pretty cool. However as with all the other cool language features - like implicit typing, you need to be responsible with them. The question is though, when do you have too many generics?

One of the peices of code I wrote this week was a generic entity retrieval command. I already had a command signature that looked a little like this:

internal void MyCommand : Command <TRequest,TResponse>

No problems here. A request, a response.Now this was ok, but I couldn't really get an entity of any type like this. I tried putting the type in the request as a parameter, but it didn't really work. So then I moved to this..

internal void MyCommand<TEntityType> : Command <TRequest,TResponse>

Now I've got 3 generic parameters. 1 that specifies the type of entity I'm requesting, and 1 each for the request and response types. I might be getting a bit zesty with my generics. However this lets me go and get a table from my context like so:

Table<TEntityType> myQueryTable = myDataContext.GetTable<TEntityType>

Which is nice I think, as it lends itself to almost any table that you've got mapped in your data context.

Now, in case there weren't already enough generics in my class definition, I also needed to know what type I was returning in my response! So....

internal void MyCommand<TEntityType> : Command<TRequest,TResponse<TEntityType>>
So I really still only have 3 types here, but now I have the TEntityType on the response as well. Do I have too many generics? Am I creating a readability and maintainability issue here? I'm eagerly awaiting the code review on this one actually... I'm interested to see what is said.

What do you think? 1 too many? 2 too many? What the hell am I doing? Would you have done it differently?

ASP.Net View State

ASP.Net View State. The extent of my knowledge up until this week consisted of:

• It a base64 encoded string that exists in a hidden field in the page

There is apparently significantly more to this beast than that. I'm not going to re-hash it here, as there are some really good articles on it already. I highly recommend this article in particular. When combined with the MSDN ASP.Net Page Object help it gives an excellent picture of exactly where view state sits in the scheme of a web page, and it's intented use.

Lets go with an example of why you'd use it. I have a repeater control. In the repeater list, I have check boxes for the rows, so that the users can group items for actioning. I can group items, and all is well, until I attempt to sort the list. As soon as I post back, my checks are all lost! Why?

Well, the most likely cause is that I'm binding my data to the repeater in, or after the page load.

The issue here lies in when the view state is loaded into the state bag. If you take a look at the two articles I've referenced above you'll get a more in depth discussion of this, but the short answer is to move the loading and binding of data back into the init page method. What this does is ensures all the controls that the repeater creates (in my case - the check boxes) are all in the control tree before the view state is loaded.

The reason for the second one being an issue is that even though I'm now binding in the init method, is that I'm also rebinding after I do the sort. This causes the view state that I had before to no longer be applicable. The answer here? Some custom view state manipulation. In this example, what we can do is ensure that during the databinding, the check box for each row is given a meaningful id - I used the Id of the item I was binding to. Then, when the check box is checked, add an item to the view state using the id of the check box for the key (view state is a dictionary) and the check box checked value (true, false) as the value.

The next step is to put some code into the page that will retrieve this key/value pair and set the checked value when the page is posted back. The most important thing here to remember is that you should be calling this AFTER the init. Yep, after. The reason? Well, if the init is before the view state load, then it makes sense that if you're attempting to use something that should be in the view state to wait until after it's loaded right? :)

I personally put my custom state handling in the override of the ViewStateLoad method in the page. It's important to make sure you've made the call to the base method before you do your loading though - otherwise you're still before the view state load.... :)

So that's a quick bit of info on view state. If you're unsure at all of what view state is, and when it's loaded, what it's intended for and what you should and shouldn't use it for make sure you check out that first article. It really is a highly valuable read!