ASP.NET 2.0 - Exploring objectDataSource
I finally got around to installing Visual Studio .NET 2005 Beta 1 (Whidbey) last night, after viewing a preview at an MSDN event in Toledo earlier this week. I was impressed with the enhanced databinding abilities included in ASP.NET 2.0--especially the claimed ability to automatically bind custom business objects--so I was eager to begin trying out this new feature.
I was a little disappointed to find so few online tutorials discussing how to use the objectDataSource object, so I started to explore the object myself. So far, my experience has been mixed. I have invested a lot of time during the past few years developing my own custom business object library, and I have developed my own standarized object format. So far, I have hand-coded everything I've ever written in .NET, and haven't found much use for the form designers and wizards in Visual Studio .NET 2003. The new objectDataSource, GridView, DetailView, and FormView components looked like an opportunity that was too good to pass up.
After a few minutes of tweaking I was able to bind one of my object collections to the objectDataSource, and get it to display in a gridView. For one, you have to manually set the "TypeName" and "SelectMethod" properties, and then select "Refresh Schema" from the smart tag menu to get started. When you first drop an objectDataSource onto the page, a wizard pops up to help you auto-configure the objectDataSource, but the built-in dropDownList doesn't let you select anything. I'm guessing they're still working on this feature.
Anyways, once you get the gridView set up, it's nice to be able to use the "Edit Columns.." smart tag to quickly generate the code required to remove the columns you don't want to display. The interface for the formView and detailsView is similary easy to set up.
Now, I'd like to explain where the objectDataSource falls short. My main issue with the object is how inflexible the "SelectMethod/SelectParameters", "InsertMethod/InsertParameters", and "UpdateMethod/UpdateParameters" are set up. I'm still hoping that I haven't explored the features enough, and that there are alternative methods to work with the objectDataSource. Here is my main gripe:
My business objects are all property based. To create a contact record, you would do something like the following:
myContact = new contact();
myContact.FirstName = "Bob";
myContact.LastName = "Smith";
myContact.ClientId = 34;
myContact.Insert();
(Each field is exposed as a public property on the object)
I'm pretty sure this is likely a pretty common practice. If you wish to set up the objectDataSource to automatically select, insert, and update your objects, they want you to use a single function in each case. So, to perform the following insert, I would need to add an additional function that looked like this:
Insert(string FirstName, string LastName, int ClientId)
{
firstName = firstName;
lastName = lastName;
clientId = clientId;
insert();
}
You also need to do the same for select, update, and delete statements. Maybe this is a pretty minor gripe? I'm currently working on a code generator for my entire business object library, and I could easily work these additional functions into the code generator, but still, I think it would be nice to have some additional flexibility in the objectDataSource. The dataBinding is smart enough to pull the data using the public properties--why can't it write back to the object using the same public properties?
I've actually only had Whidbey installed for about two hours, so I may be missing something here, but the lack of online discussion on the matter led me to write this blog. If anybody has any additional insight on the subject, please let me know. For now, I'm going to continue exploring my new installation of VS.NET 2005.
I was a little disappointed to find so few online tutorials discussing how to use the objectDataSource object, so I started to explore the object myself. So far, my experience has been mixed. I have invested a lot of time during the past few years developing my own custom business object library, and I have developed my own standarized object format. So far, I have hand-coded everything I've ever written in .NET, and haven't found much use for the form designers and wizards in Visual Studio .NET 2003. The new objectDataSource, GridView, DetailView, and FormView components looked like an opportunity that was too good to pass up.
After a few minutes of tweaking I was able to bind one of my object collections to the objectDataSource, and get it to display in a gridView. For one, you have to manually set the "TypeName" and "SelectMethod" properties, and then select "Refresh Schema" from the smart tag menu to get started. When you first drop an objectDataSource onto the page, a wizard pops up to help you auto-configure the objectDataSource, but the built-in dropDownList doesn't let you select anything. I'm guessing they're still working on this feature.
Anyways, once you get the gridView set up, it's nice to be able to use the "Edit Columns.." smart tag to quickly generate the code required to remove the columns you don't want to display. The interface for the formView and detailsView is similary easy to set up.
Now, I'd like to explain where the objectDataSource falls short. My main issue with the object is how inflexible the "SelectMethod/SelectParameters", "InsertMethod/InsertParameters", and "UpdateMethod/UpdateParameters" are set up. I'm still hoping that I haven't explored the features enough, and that there are alternative methods to work with the objectDataSource. Here is my main gripe:
My business objects are all property based. To create a contact record, you would do something like the following:
myContact = new contact();
myContact.FirstName = "Bob";
myContact.LastName = "Smith";
myContact.ClientId = 34;
myContact.Insert();
(Each field is exposed as a public property on the object)
I'm pretty sure this is likely a pretty common practice. If you wish to set up the objectDataSource to automatically select, insert, and update your objects, they want you to use a single function in each case. So, to perform the following insert, I would need to add an additional function that looked like this:
Insert(string FirstName, string LastName, int ClientId)
{
firstName = firstName;
lastName = lastName;
clientId = clientId;
insert();
}
You also need to do the same for select, update, and delete statements. Maybe this is a pretty minor gripe? I'm currently working on a code generator for my entire business object library, and I could easily work these additional functions into the code generator, but still, I think it would be nice to have some additional flexibility in the objectDataSource. The dataBinding is smart enough to pull the data using the public properties--why can't it write back to the object using the same public properties?
I've actually only had Whidbey installed for about two hours, so I may be missing something here, but the lack of online discussion on the matter led me to write this blog. If anybody has any additional insight on the subject, please let me know. For now, I'm going to continue exploring my new installation of VS.NET 2005.
0 Comments:
Post a Comment
<< Home