ObjectDataSource, I hardly knew ye. 

Once I did get to know you, I didn't like you.  You see, when I saw the ObjectDataSource demos I thought "Finally, Microsoft understands me".  I did a couple of quick tests of the designer support and functionality and was pleased with the results.  Tonight I created a "service agent", a class to wrap access to an out of process call, in this case playing around with the Amazon.com affiliate program again.  For operations that require input parameters to the ODS you can often just tie the parameters to a control on your page using markup and with one line of code:

protected void searchBtn_Click(object sender, EventArgs e)
{
  amazonDs.DataBind();
}

gets the results out of the service agent class.  The ODS pulls the parameters our of the configued form fields and away we go.

Then I realized I am still a misunderstood objects maniac lost in a world of DataSet coding.  Once my List<CustomType> is read from my middle tier object it no longer exists.  Anywhere.  I had deluded myself into thinking that things like "SelectedRow" in a GridView would give me something I could cast to my CustomType, that various GridViewEventArg/ObjectDataSourceEventArg.DataItem would give me something I could cast back to my custom type.  Maybe GridView.SelectedRow would contain a set of values I could use to rebuild my entire object...

No, no, no.  I will say for some types of things the ODS is still useful.  As long as you don't mind looking up your objects using a DataKey and/or your model fits in with this a little bit better than mine does I would still prefer this over an SqlDataSource  So unless I find some obscure method that is not presenting itself right now I am back to programming the same way I did in ASP 1.1: Get ArrayList of Objects, put in session to refer to them later, configure <Columns> in Grid control, DataSource, DataBind, etc.