Geeks With Blogs
Adrian Hara Working through the .NET maze

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 :)

Posted on Thursday, March 1, 2007 8:31 AM | Back to top


Comments on this post: GridView, ObjectDataSource and BusinessObjects bummer

# re: GridView, ObjectDataSource and BusinessObjects bummer
Requesting Gravatar...
From my experience you don't need to specify all the fields as primary key. If you use the DataObjectTypeName, the ObjectDataSource will create an instance of that type and pass that instance to InsertMethod or UpdateMethod... But not all fields of that object will be populated... It can only populate those fields which are bound in the DetailsView or similar. That was my experience.
Maybe you defined additional parameters on the Insert or Update methods. You know, make one of the parameters the "object" type. I think that in that case the ObjectDataSource doesn't do anything with the DataObjectTypeName. It's then up to you to do all the dirty work (create instance of business object, populate fields from controls on the page, assign it as value for a parameter in Updating or Inserting event).

And for DLinq....
That stuff really looks strange in the eyes of an ASP.NET developer... At least now in my eyes it does... I've used it as the data layer in one project and now, when I've done nearly half of it, I'm considering replacing it in the data layer with some simple ORM tool. The problem I'm having is the memory consumption which is around 100MB and 150MB... And that's only for several pages and tables. My hosting provider only allows under 100MB, so the app keeps restarting...

Enough about my problems...
I just wanted to explain something about the DLinq. If you use the Attach method for updates, you can't (should not) use the same object you received from the ObjectDataSource. Then there is no changing in the data. I've done what you've done. Get the object fresh from the database using the id. Then there's no need for Attach, because DataContext (DLinq) is monitoring for changes... Then I update fields one by one with the values from fields of the object received from ObjectDataSource. That only leaves me with the responsibility of keeping the "field setting" list in the Update method in sync with the fields used on the data form.
Left by Dragoljub Ćurčić on Mar 30, 2007 8:13 PM

# re: GridView, ObjectDataSource and BusinessObjects bummer
Requesting Gravatar...
Unfortunately I wasn't able to get it to work, not even with the fields that were actually used from the data object, UNLESS I specified each and every one of them as primary keys. I was trying to bind to a GridView.

Regarding Attach, the basic idea of using it is to avoid doing a Get from the database, if you're happy with the data object you have coming from the UI (or whatever) layer. You just Attach it to a DataContext, replay the changes and are good to go. This is exactly why I'm not happy with getting a partially empty object from the ObjectDataSource, because I first have to do a Get, then replay changes and save, whereas if I had gotten it correctly, I wouldn't have to hit the DB with a Get.
Left by Adrian Hara on Mar 31, 2007 5:16 PM

# re: GridView, ObjectDataSource and BusinessObjects bummer
Requesting Gravatar...
I know it's a while since the last post but maybe there will be people that will find this helpful.

I run into the same issue and it seems that only the bound columns are passed to the new instance constructed by the objectdatasource

<asp:BoundField ...

so Adrian, I guess you were using a template fields just like me.
Left by Alex Botez on Feb 13, 2008 9:51 PM

# re: GridView, ObjectDataSource and BusinessObjects bummer
Requesting Gravatar...
My answer was incomplete; I was using a template field were the edit item template was bound with Eval (so 1 way binding). The appropriate is Bind for 2 way so in this case the values will be passed also towards data storage.

At least this was my context.
Left by Alex Botez on Feb 13, 2008 10:15 PM

# re: GridView, ObjectDataSource and BusinessObjects bummer
Requesting Gravatar...
sir i want to use yes/no answer with asp.net
Left by saurabh mishra on Mar 30, 2008 9:54 AM

# re: GridView, ObjectDataSource and BusinessObjects bummer
Requesting Gravatar...
sir i want to use yes/no answer with asp.net please give coading in vb.net using sql server
Left by saurabh mishra on Mar 30, 2008 9:55 AM

# re: GridView, ObjectDataSource and BusinessObjects bummer
Requesting Gravatar...
This is weird. I've tried several times, and my ODS returns an entity with fully populated properties on Update. The Delete is different, and it behaves like you described, i.e., only the key property is populated (but then, this is what I need, the ID of the object to be deleted).

Attaching this object in order to save the changes is a tough experience. I haven't succeeded so far; my next step will be to try and change ConflictDetection to CompareAllValues. Theoretically, I'll have to pass two objects to my Update method, one with original values, the other with the updated ones. I'll be able to use the overload of Attach that takes the two versions.
Left by ulu on Nov 09, 2008 11:37 PM

Your comment:
 (will show your gravatar)


Copyright © Adrian Hara | Powered by: GeeksWithBlogs.net