I'm sure you're all familiar with the GridView in asp.net 2.0. It's a great control, and coupled with the new (well, some time back they were... :)) data source controls it's big aid to rapid development. I've worked with it before, but I always used DataSets as data containers. Now, on a little project I'm working on, which uses DLinq, I resorted to custom objects.
It worked rather good, until I got to the "save back to persistence" part. As you might know, the ObjectDataSource control supports two modes of operating in conjunction with the actual business object that does the work: it can either call this object's methods with a whole lot of parameters OR with ONE single object (a so-called data object), which would usually be the very entity you're trying to save (if you're not familiar with this stuff, read Manuel Abadia's excellent tutorial series on the ObjectDataSource).
I chose the data object approach, since I figured that by having the ObjectDataSource call a method on my business object with a ready-made entity (like Update(Customer cus)), I'd just instantiate a DLinq DataContext, Attach the entity to it, replay changes and call SubmitChanges. The "bunch of parameters" approach would be similar, but with a slight disadvantage: I'd have to GET the entity from the database first, then change its fields with the new values. So a db call is something worth avoiding, right?
Unfortunately, upon choosing to go the data object way, I ran into the brick wall: when my business object's method was called, with the exception of the primary key field, all other fields of the data object were just empty (default values). For some reason the ObjectDataSource wouldn't be able to fill a valid... Customer or whatever object and send it down. After googling a bit without any luck I dug further and after some time I found a workaround: for the stuff to work, you have to specify all data object fields in the DataKeyNames property of the GridView! Kind of stupid, so I thought it can't be right. Armed with this "knowledged", I googled again, and found another poor soul who had the same problem and came to the same conclusion: check it out.
So I reverted back to the parameters approach, always sending one parameter, the primary key of the entity. Then, as stated before, the business object would first do a Get from the database and then proceed on its merry way. A little sad, but, as always, if you have any suggestions, please share :)