Whidbey DataSources - Are they Cumbersome?

So I've had a bit of time to think about the new DataSources objects that are in ASP.NET 2.0, and I think I've come to the conclusion that ultimately they'll be more cumbersome than helpful. I state this in reference to how a lot of my applications are built, in which each page will have a TON of data access to do, all requiring their own business object to be called.

While the concept of using DataSources is very cool and easy to use when creating simplistic web applications, its going to be more cumbersome for more advanced applications. Now, why would it be cumbersome? Well, its taking the whole separation of code and design back to the old days, where its mixed together.  With the advent of .NET 1.0, we had a distinct separation, but it seems this distinction line is fading extremely fast in lue of Visual Studio 2005.

It is also going to be more cumbersome because instead of having distinct areas for server controls, and having your data binding methods in code, you're going to be adding more overhead to the HTML structure of a webform. So, instead of just having (in HTML):

Drop Down List 1: <asp:DropDownList runat="server" id="ddl1" />
<br>
Drop Down List 2: <asp:DropDownList runat="server" id="ddl2" />

you now have more HTML to write, which can be confusing to designers or newbies. In fact, I'm an advanced developer and I still get confused with all the extra HTML that is required:

Drop Down List 1: <asp:DropDownList runat="server" id="ddl1"  DataSourceID="..." />
<asp:SqlDataSource runat="server" ..... />
<br>
Drop Down List 2: <asp:DropDownList runat="server" id="ddl2" DataSourceID="..." />
<asp:SqlDataSource runat="server" ..... />

Sure, this isn't as complicated, because its simplistic. Imagine needing 15 drop down lists, all coming from different data sources, as well as binding a datagrid, and some detail information. That can amount to about 17 of those DataSource items, on top of your regular HTML. Now imaging that being step 1 of a wizard type UI, and having the same type of step 5 more times. Do you see what I'm getting at now?

So, is there any way of using these DataSource controls with regular HTML markup? Maybe, but I would have to propose a section that you define in your HTML page so that everything is contained in 1 place for ease. Other than that, I think I will be ultimately dreading using DataSources for future projects because of this primary problem.

1 Comment

  • Just thought I'd make a few notes, based on some info I got back in August at Redmond. First off, you don't HAVE to use the new DataSource objects. Second, ASPX files are not HTML markup. Even HTML tags are processed by the ASP.NET runtime, and exist as objects on a call graph. They're just not accessible unless you add a runat=server attribute.



    In regards to the UI design aspect, I would argue that, if you ahve 15 dropdown lists, a datagrid, and some detail information, then you have a poorly designed UI.



    The datasource controls were designed so that you didn't have to write procedural code. If you don't like them, write procedural code. You don't have to use them declaratively, you can always use them programmatically too.



    Also, you don't have to have the datasource control right by the dropdown list. So put all the datasource controls at the end of the file. Then they're out of the way.



    Finally, those controls were designed to make it easier to interact with data in a visual designer. Yes, it blurs the line RE: separation, but at the same time, you can make changes to your data sources without recompiling the app.

Comments have been disabled for this content.