Serialize, then deserialize, vs. deserialize, then serialize: Which order and why?

I don't see why that should have anything to do with sorting.

Neither do I Andy, but you never can tell, what if they sort in the db query rather than in the ui (silly, I know but stranger things have happened)...  ;)

-saige-

Sorting in the DB query itself makes perfect sense.  DB's can index fields and sorting on an indexed field is very efficient (unlike sorting on unindexed fields).  But the DB drivers should take care of the grunt working in making any data available to the app in a suitable format.

I think I'm gonna close this question as I've gotten some good feedback, and thank you in advance to those who contributed. What I noticed (to your points Kyle & it_saige), is that, in the example that I've been given to model from, they are De-serializing the data into an object, and then, after sorting they serialize and put the same data into a session variable before continuing on to determine which direction to sort the column that has been clicked etc. So, Kyle/it_saige, by your explanation(s) above, they unpacked it into an object first, but then packed it [in]to a session variable which is "sending" the data to a different [storage] location. The utility that pulls the data is from a data access layer which, in this case,  is definitely a separate application domain. Would that be an accurate way to apply your explanation?

Thanks to all who contributed.